Releasing

Release early and often. Period.

Do whatever you can to make that happen. This is true for all sizes of companies. One man company or 60000 people company. Tweak your processes so you can release often and with confidence. I have seen companies that release once a month. Some even worse, that release once every quarter. Any startup can come in and dominate a company that releases once a month unless they have a huge moat.

Sometimes release is delayed because of a big feature that is merged in the trunk and there are many bugs that surfaced in release testing. To mitigate this, keep a system to manage feature flags. Release big features behind flags and ship code regularly. Release at least twice a week. More the merrier. Make it a rule of thumb. Quite often, the time between two releases is a good indicator of how bureaucratic a company is.

In a very small company releasing is easy. You can just run a command on your machine and ship multiple times a day sometimes for the web. A decent-sized company should be able to manage daily or whenever needed. However, that takes good discipline, engineers, and processes to make that happen. You have to have a good DX, do code reviews on time, have good feature flagging, good CI and CD. Once the release is done, run E2E tests, set monitoring, and observability to make sure all works well. Having a good DevOps culture can make this happen.

When you release often, you don't have to make a release wait for some feature or bug fix. Think of release as a train that features/PRs/developers have to catch. Not as a tool to ship a fix or features. Set a cadence and release. Aim for a true CD system. Do not wait for that one last PR to get merged in the trunk to release. Once you release automatically and quite often that PR can catch the next train. Remove managers from the equation and this will be easier to do. Break that cadence only in case of something urgent. Urgent means the app or some important function is not usable anymore. Releasing on Friday should be done with caution. Probably never unless you have a strong automated test suite that will ensure everything works after a release.

Git branching strategy is important. Long-running feature branches and release branches encourage risky merges and delayed releases. Try to keep your structure simple and release from the trunk. Use tags for release. Do hotfixes in the trunk, not in release branches. Try as much as possible to not checkout release branches. When you do that, you set yourself up for delay in releases. Keep that sense of stability and sacredness about the master/main branch that it can be released anytime. Keep branches/PRs less than 500 lines of the diff. It helps you ship code quickly and keep risk to a minimum.

Automate as much as possible that includes testing, merging, deployments, releases, release notes and etc. A real-world check here is that true CI/CD is not easy if you never had it in place. The good news is that all of this automation can be done in steps, one at a time. You don't have to go from nothing to a complete CI/CD system. You can start automation, one thing at a time, and eventually achieve near perfection. Refactor in iterations.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.