Architect Tips

How often should you be deploying your software to production? Welcome to Architect Tips, presented by Clear Measure, a software Architecture company, empowering .NET development teams to be self-sufficient, able to move fast, deliver quality and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to [email protected] and the next tip could be yours.

Welcome to Architect Tips. I'm Jeffrey Palermo and today we're going to talk about how often to deploy to production. And if you have a question for Architect Tips, send it to [email protected] and from those submitted, we will pick a question. And if I can put it in to a short five-minute bite-size chunks, I'll do it. Otherwise, I’ll just send you an e-mail and answer it for you. So how often should you be deploying your custom .NET software applications to production no matter the size of the software or

individual chunks? Let’s dig into that and you're going to answer the question for yourself, but it's going to depend on a number of factors. The first one and foremost is the pace of your business. And if your business needs to give new things to customers once every three months. Well, then deploying to production... The minimum to deploy to production is once every three months. If your business needs to roll out changes to customers every week or even every day, then that's the slam dunk answer. Now, let's suppose that your business doesn't really intentionally roll things out to customers, but every few months you are still making improvements to the software, you're increasing the quality of your telemetry. You're making it run faster, you're making it scale better on fewer server resources and so you'll still be doing production deployments even if you're not actually giving anything to the customers and so the answer is you need to deploy at least as fast as your business moves and faster for other scenarios. Now let's back up from that question and talk about the pace of your testing because if you are testing performance, improvements or stability improvements, well that's also going to determine the frequency at which you deploy. Even if you give, let's say, product management the button to press to production and say, hey look, build such and such as ready for production.  As soon as you press that button, it's going to go. If you're ready, and they're never waiting on engineering, that's success. Product management should never be waiting on engineering, engineering should be waiting on product management. Whatever form that takes in your company, whether it's Joe next door or whether you are in a larger organization with more formalized product management. But the pace of your testing can determine how often you deploy to a pre-production testing environment because every DevOps environment has three categories

of environments. The first is production, everybody has at least one of those. Next is a manual test environment. You need at least one of those, a lot of organizations have many of those, that's one category. The third category is automated test environments or test automation environments. I like to call those environments The TDD environment to invoke test-driven development so you have three categories of testing. Now the pace of your development is also going to impact how often you would deploy, not only to production but to test and your test automation environment and that the raw ability to deploy quickly comes back to how you do code branching, and if you are doing branches that live for days and weeks on end, you're not going to be able to do production deployments on any kind of frequency. So you need to have every individual change beyond its own short-lived branch. And when I say every change, if you're changing the way a button operates, that’s a branch. If you are adding a new screen, that's a branch. If you're adding a new field to an existing screen that also adds a corresponding column field to a database table, that's a branch and no branches should live more than two days. Every branch should be targeted to live one day. Something that I can get done in one day and oh two days, That's my fallback. Okay, maybe it does take me two days but if you have a branch open for three days and four days and five days; that means that either it was too much work or we didn't understand the design that we are going for, and I didn't really have a plan for implementing it or something else came up. Some new information I learned. And now I've learned it's more of an effort than I thought it was. So the size of the branch is going to make a difference. Now, here's another related question. How do we know if we're okay to deploy? Oh, we can hit the button and press to the point. Now I'm assuming you have automated deployments we can come back later but how do I know we’re okay to deploy when it comes back to quality in our pipeline. You know, invokes the metaphor of water...you want the water to be clean in the pipeline. You don't like to be dirty everywhere and then attempt to fill through at the end. So these are DevOps questions. Your pipeline should be able to answer for us.  Is the change that I just made okay to share with my team?  Well, that gets answered by the private build. That's the first tier in continuous integration. Does my change play well with other changes, other code changes elsewhere on my team? That's the integration build. The second tier of continuous integration and then third, does this release candidate, does this build that has been produced with all of our changes on the team, Does it still deploy? Does it still startup? Does it still generally function? Well, that is the answer of the third phase of continuous integration, which is that first deployment to the TDD environment or the test automation environment, where no humans really go. It's just to vet the release candidate. And then, as we get further down the line, if the TDD environment and in the acceptance test Suite, that runs their passes. Well, now we know, we're okay to share with stakeholders or product management testers. Whoever we give it, give that bill to beyond the engineering team and then finally, if they run it through its paces and they don't find any issues well now it's okay to share with the customers and so those are our answers as to whether it is okay to deploy to production. Whether we're okay to deploy to a test environment and whether okay to even share a branch with our team. So I hope that helps. And as always, if you need any architecture help, at Clear Measure we’re a software architecture company, we exist to help you move fast, deliver quality and run your systems with confidence. We want you to be able to do more internally so that you and your team can perform at another level and you're more than capable to deliver for your customers and to deliver her to your company, which is fantastic. Thanks for now.

Thanks for watching Architect tips. If you would like help improving your team speed, quality, or software stability. Send us a note to [email protected] on behalf of everyone at Clear Measure. Thanks for watching and may God bless you.