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.
100%. I think observability and monitoring are the hallmark of a great engineer. I know there are different opinions on this but it's one of the reasons I prefer on-demand deployments. My next post is going to be about observability.
I remember at one company (~7 years ago) we had a person with official title "Release Manager" just to manage these steps mentioned in your post, distribute release notes, etc. Wondering if any company still does that as now it is much more automated.
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.
100%. I think observability and monitoring are the hallmark of a great engineer. I know there are different opinions on this but it's one of the reasons I prefer on-demand deployments. My next post is going to be about observability.
I remember at one company (~7 years ago) we had a person with official title "Release Manager" just to manage these steps mentioned in your post, distribute release notes, etc. Wondering if any company still does that as now it is much more automated.
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