Does it seem like you’re always waiting for something to be completed before you deploy your application to the User Acceptance Test (UAT) environment? You want to wait for the development team to fix the last few bugs. They have not yet agreed on which transaction manager to use. We’re only a couple days away from finishing feature X. We might have time to get feature Y in. There is no end to the myriad of details to sort out and questions to answer before you deploy.
Not only that, the product owner or project manager is getting impatient. You promised her it would be deployed two weeks ago, but due to factors beyond your control there’s still more work to do. The Quality Assurance (QA) folks have their test scripts ready to go, but they’re just twiddling their thumbs while they wait for you to deploy the application.
And as if that wasn’t enough, you’ve been thinking about the production deployment. There are a million little details to work out, and you’re not confident you’ll have the time to sort them all out between the UAT and Production deployments. Oh, and you’ll probably need to set aside an entire Sunday for the Production deployment, because you know there will be a ton of problems to sort out.
There has to be a better way
Suppose you could make these deployments so routine they become non-events. Why can’t your team perform the deployment, make any necessary configuration changes, do a smoke test, and you’re done. Suppose you could reduce your stress level by orders of magnitude so that you could get more work done? Hey, maybe you could get some of your home life back?
Deploy Your Application Early, Deploy Often
Deploy something to UAT. It doesn’t have to be a fully-functioning application. Just get the smallest piece of usable functionality out to UAT so you can get some feedback on it. The first few times this feedback may just be the problems you solved during deployment. Do it now, and again next week, and again the week after. The deployments will be difficult the first couple times you do it. But by deploying early you give yourself plenty of runway to sort out big problems. You’ll start learning lessons about the deployment process itself. You’ll probably forget some important components or steps too; add them into the deployment process for next time.
As you repeat this deployment, look for opportunities to automate the process. Can you replace manually-typed, error-prone commands with a script? Do you have any APIs you can use for automation in place of a graphical user interface that a human must use?
Make sure you place the scripts you develop under source control. You’ll know who changed what, and when they changed it.
All this helps mitigate risk, The risk of an outright deployment failure. The risk of unexpected problems that extend your production deployment window. The risk of problems appearing once your customers resume using the application after Go Live.