“Do not deploy on Friday” is not a joke after all even if you have continuous deployment. With deciding to deploy anyway comes the subtle concern, what’s the worst that could happen?
In this article, I will not concern myself with the unwritten rules of software engineering, even though I’m so tempted to, but will focus on deployment and release management.
This article aims to expound on the difference between software deployment and release management. I’ll try to explain my points in layman's terms.
What is Software Deployment?
When software developers are done with code for a product/service, they make the software available to be used by users and other programs. This process of making the software available is called Software Deployment. It could be done on test servers, a production environment, or any other place where the code would run.
In agile development, getting incremental changes out to users as quickly as possible is a norm. And to achieve this, every new feature pushed or released to production has to undergo some form of testing.
- Continuous Delivery: Once a new feature has passed automated tests, it is pushed to a clone of the production environment for manual testing of the new code. The focus here is on preparing the code changes to be released. Technically, the push of a button to get the changes into production.
- Continuous Deployment: Here, any code that passes testing moves straight up (is deployed) to the end-users—No human intervention or manual approval is required. The goal here is to continuously release code changes into the production environment.
Feature flags can be used to manage continuous deployment. This simply allows the deployment of features, one at a time—Micro-deployments of microservices. It’s all about getting new features to the end-users at the pace that they are created.
NB: Deployment is when you install a software version in an environment.
What is Release Management?
As the needs of real users evolve, the collaborative effort of the cross-functional teams in a business is to ensure that a software solution is released to the users, that caters to their needs. The process followed to achieve this release is called Release Management.
Release Management entails overseeing the planning, scheduling, and controlling of an entire software build through every stage and environment involved, including testing and deployment. Release to users is typically the final part of the software development life cycle (SDLC).
Some businesses go beyond the technical processes of release management to include managing adoption. In fact, some effort is required from the product, development, support, sales, and marketing teams, etc, for the successful management of a release.
By decreasing risk, streamlining deployment efficiency, and enhancing customer value, release management aids in keeping everyone aligned and focused on the broader scope.
NB: Release is when you make software available to users.
How Often Should You Release?
Certain considerations need to be accounted for to know how often to release features. Continuous release is not a bad idea. But generally speaking? Errrmmm! It really depends.
The type of business, product, and customers you have largely informs the release cycle frequency.
Should product managers keep the features coming, or is it better to dole out features on a schedule? This would be up to your customers. How frequently do they expect you to release new features?
In summary,
Release != Deployment
The overall focus for teams is to vet how their processes help to accelerate value delivery for their business. Because actually, users care less about what methods are utilized to solve their problems. They would always stay as long as they get real value for their money.
Can you deploy on Friday? Errrm! Yes.
But should you? This is the right question.
Thanks for reading this far.