Great software is released software! Today’s post is about how to release software to production. First, we will cover the required steps before landing a pull request to the main branch. Build is green Linter is green All unit tests are passing Pull request code reviewed and approved
Apr 26, 2023·edited Apr 26, 2023Liked by Georges El Khoury
I want to emphasize the importance of having good observability and monitoring for engineer driven deployments. I've seen it happen again and again (and I've made this mistake) that people deployed things without keeping an eye on the dashboards, or even having proper metrics in place to begin with. In our deployment guidelines we've added as step #1, bring up all the dashboards that need monitoring and keeping an eye on, then proceeding with the deployment.
The discussion here contains hidden assumptions about architecture of the application, that are not discussed. For example, doing a release for the desktop-based application will be different then doing a release for web-based application, simply due to the number of users that need to perform some action related to a new release. At the same time, doing release of the application with central database could be quite different to doing release of the application without database.
So, before talking release strategies/frequencies one need to talk about application architecture/number of deployment points/how many versions of the application one needs to maintain simultaneously
I want to emphasize the importance of having good observability and monitoring for engineer driven deployments. I've seen it happen again and again (and I've made this mistake) that people deployed things without keeping an eye on the dashboards, or even having proper metrics in place to begin with. In our deployment guidelines we've added as step #1, bring up all the dashboards that need monitoring and keeping an eye on, then proceeding with the deployment.
The discussion here contains hidden assumptions about architecture of the application, that are not discussed. For example, doing a release for the desktop-based application will be different then doing a release for web-based application, simply due to the number of users that need to perform some action related to a new release. At the same time, doing release of the application with central database could be quite different to doing release of the application without database.
So, before talking release strategies/frequencies one need to talk about application architecture/number of deployment points/how many versions of the application one needs to maintain simultaneously