On the fifth day of Christmas, my true blog gave to me… Five Golden Rules!

…four Community Sites, three Maturity Models, two Sitecore PaaS features, and Sitecore in a NuGet feed.

Last year I provided a list of golden rules for DevOps and this year we tackle golden rules for continuous delivery!

#1. Sustainable schedule

Before adopting continuous delivery, the team needs to agree on a release schedule that can be repeated again and again and again. If the schedule is not sustainable, the team will eventually burn out and start missing delivery.

One good starting point would be looking at a monthly ‘patch day’, much like IT teams do for managing windows updates. If that is too frequent for the team to operate, just make sure the schedule does not exceed 90 days. Longer than that and we are not really gaining any ‘continuous’ value.

#2. Small batches

In order to support our repeated and sustainable schedule, the work packages defined for a release must remain as small minimum batches. Much as an agile team would determine whether a User Story was small enough to be completed within a Sprint, the release management team needs to determine whether work packages are small enough to fit within a release.

#3. Automate specialty knowledge

In order to support continuously deploying to production, we need to make sure that anybody would be able to execute the deployment. At the very least, we need to make sure that we aren’t locked into extremely specialized and in-demand team members.

This means ensuring our deployment process has automation to capture the specialty knowledge and allow non-specialists to execute the deployment. For example, in the Sitecore realm, this often means being able to automate content and file deployments so that a Sitecore developer is not required to push to production.

#4. Continuous Testing

Many teams who use long and heavily staged projects have large testing phases which can take weeks or months to complete as they attempt to cover all of the new functionality. There is often a heavy manual component in here as well.

However, this will not work with smaller batches being continuously pushed out. This is often the biggest adjustment teams need to make as we move away from the ‘throw it over the wall to QA’ model and instead embed the test team within our delivery teams. We also need to automate some of the testing in order to repeat more often and execute more quickly. Luckily, with smaller batches, there are fewer changes to test as well.

#5. Involve everyone

Continuous Delivery impacts the entire flow from initial requirements and design through to operational support and maintenance. This is not just about building new code! That means making sure everybody is on the same page and aligned to be able to adjust and repeat on a regular cadence.

Some teams may not be ready for this adjustment yet. Development teams who have been operating on regular sprint schedules can adapt rather quickly, but maintenance and support teams that are used to long periods of time before new functionality is delivered to production may not have processes in place to continuously receive and support new work packages. Similarly, business team members who are used to defining extremely large projects once a year may not be ready for the continuous involvement required to define requirements for smaller packages.