Go Lean: High Velocity, High Quality Sitecore Deployments

Follow up on my Sitecore Symposium Talk 2016

I had the wonderful opportunity be invited to talk about Lean Development practices and strategies for continuous delivery for Sitecore this week at the 2016 Sitecore Symposium this year. The topic of Lean Development and Continuous Delivery is a big one and trying to talk about such a huge and important task in 45 minutes forced me to not only leave out some important points, but I went through things very quickly. I wanted to take the time to summarize what I thought were the important take-aways of the talk.

• Think backwards
• Fail fast
• Every artifact has one owner
• Deployments are part of your build
• Testing is part of your deployments
• Good Architecture is important
• Code in the mainline, checking-in is step one of a deployment
• Automate everything

Think Backwards

Lean is a strategy that says that you need to create a flow of tasks and optimize the whole rather than individual tasks. That means you cannot define the output of one task without understanding the required input of the next. Before you even create your Visual Studio Solutions, you should know what your deployments will look like, what hooks you need in your code to verify it is working in production, and what will happen if the test tell you something went wrong. The solution should reflect this and developers should ALWAYS know how the change they are making will get to production. This is also a huge leap forward in creating a DevOps culture in your organization.

Fail Fast

Nobody likes the idea of failing but failing is a very important part of learning. As any seasoned Sitecore Developer knows their are significantly more wrong ways of doing things than right. Many of us have learned some of these the hard way, at 4:00 AM on a production deployment call the morning of a big product release. Although times like that we learn a bunch, wouldn't it have been nice to learn these lessons before we got to production. Tools like unit tests, SonarQube, custom TDS content validators, StyleCop, SitecoreCop, ReSharper, Sitecore.Pathfinder, etc. can get you learning what not to do before you even check-in your code.

Every Artifact Has One Owner

Many of us who have survived a Sitecore upgrade have learned NEVER to update Sitecore's own config files but instead to use custom patch configs to update config values. The patch config strategy allows us to draw a line between what SItecore "owns" and the customization we "own". This strategy should not only apply to configs but also 3rd party DLLs, content, and it should also include the relationships we have with others such as modules we download from the Sitecore Market Place and our own content authors.
It is very important that developers own Templates, Layouts, Renderings, Rule Definitions, Standard Values*** (<--VERY IMPORTANT), and structural parts of the content tree. These are things where the source of truth is source control. Very bad things happen when this types of items become out of sync with source control and what developers are developing against. On the other had your Content Authors and Designers Own the content. The source of truth for these items are the production Sitecore CMS. Developers should never overwrite content in production, that can easily lead to the choice between hours of lost work or a complete restore from backup of the Master database.

Deployments are part of your build

In continuous delivery every check-in is a potential deployment to production. Our assumption is that a build will go to production unless we discover a reason it can't. Developers are trained that a broken build requires everyone to drop everything and fix it. A deployment package is the result of a build. The build should be broken if the deployment package is not deploy-able. Code that can't be deployed is useless no matter how elegant it is. When the output of a build is undeployable, the developers should stop everything and fix it.

Testing is part of your deployments

I will be the first to admit that it is not always possible to do 100% of your acceptance tests in an automated way. That said, I have never seen a situation where it is not possible to do any testing at all. You should not need a team of testers to tell you that the home page of your web site is returning a 500 code and displaying the Yellow Screen Of Death. Automated acceptance tests will allow you to know weather your deployment worked, your environment specific configuration values are correct and all your integrations are working before anyone even invests the time to look. The more coverage you have the less time is needed for validations and the more deployments you can do. The more deployments you can do the smaller the changes are and the easier everything gets.

Good Architecture Is Important

During my 45 minute demo it did 3 deployments and 1 rollback and at the end I showed you the tools I used to do that. If someone came in late and just wrote down the tools without seeing the beginning of my talk they may think that if they just use those tools they can make deployments easier. That is not necessarily the case. I showed the tools that work for a unique company in a unique situation. The talk was not meant to say, "use TeamCity instead of Jenkins, or TDS instead of Unicorn." In many situations even I would choose different tools but that's not the point. The point was that everything effected the architecture quality, maintainability, best practices, and validations and deployments.
In the book Leading Lean Software Development: Results Are not the Point By Mary and Tom Poppendieck one of the first things that talk about is importance of having a well defined architectural vision and that being a key to success in any agile framework. Without a good and consistent architecture everything I am talking about here will quickly crumble into a big mess.

Code In The Mainline

Continuous Integration (CI) is the first step in creating a Continuous Delivery (CD) flow/pipeline. Since CD requires CI people need to understand that attempts to create isolation from others or other components will break your CD flow. The most popular strategies for creating isolation is branching in source control. Coding in the mainline, or mainline development is a technique for continuous integration that requires all developers to commit (or check-in) to the mainline (or trunk) of source control. All integration and merge conflicts are ironed out immediately. You can read about this in more detail here.

Automate Everything

Developers and testers are too smart to do repetitive tasks (at least they should be). People should not be robots. A developers job is to solve problems that are unique and difficult. A tester should be spending his time finding new and inventive ways of breaking stuff. These are the reasons we like our jobs and got into this in the first place. Also people are not as fast and reliable as computers in executing well defined algorithms. Automation is the key to not only efficiency and quality, but it is also the key to happiness. Whenever you feel like your not engaged in a task because you've done this before automate it. Automate tests, code generation, builds, deployments, and if you have time automate the coffee machine. You'll thank me later.