We won’t go into specifics here, as each option has their own set of advantages and disadvantages.
There are numerous options for continuous integration products. Phase 1: Automate the deployment process Continuous Integration In this post, I’ll cover phase one at a high-level, as we’re still working our way to the ultimate goal of continuous delivery. A two-phased approach made the most sense for us: Project Phases Your clients will thank you later.įor us, however, moving directly into a continuous delivery strategy is much harder, as our solution is much more mature than a new build with a considerably large set of content and a need for high availability within the editorial team. For any new build, this should not be an after-thought, but a requirement before going live.įor those of you building new Sitecore implementations, please advocate for this up front rather than under consideration as a “phase two” deliverable. Getting there is much easier during a new build, as dependencies are much more manageable. The ultimate goal is to deliver continuous deployment, a process in which developers can commit directly to the master branch, kicking off builds, a suite of automated tests, then packaging and deploying updates seamlessly without interruption to end-users and editorial team members. Sitecore Symposium specifically had standing room only for talks on continuous deployment and delivery. Don’t think this is a need across the Sitecore community? Attend any session at Sitecore Symposium or user group centered around this topic.
#Teamcity octopus manual#
Having gone through the pain of manual deployments using build scripts, diff tools and carefully updating of configuration files, it’s easy to see the need for a reliable and repeatable deployment process. Once thought of as a luxury, an automated deployment strategy is now largely considered a necessity as Sitecore expands in terms of complexity, dependencies and standardization of configuration.
0 kommentar(er)
