It's obvious that good communication is critical to the success of any project. On a recent large project, the many layers of communication needed to coordinate some daily operations have become even more clear to me. In particular, I've become attuned to something that I never realized would be relevant to a PM: release management.
We've been working on a big, complex app for almost a year that has had up to eight front- and back-end developers working on it at once. On top of that, we've been simultaneously working on large features, small features, quick support fixes, and QA. With all that in play, it meant that once this app was in the wild, we would need a rock-solid release management plan.
In landing on a release process, our team first talked through the scenarios that our release process would need to support:
Ongoing development of large features that would need to stay isolated until completion and approval by the client
Frequent releases for small and medium tasks that aren’t urgent, but still require a separate QA/approval process by the client
Critical fixes that need to go live ASAP
It was clear that flexibility needed to be at the core of our process. We didn't want to slow down ongoing development, but needed to be able to release frequently and react quickly to emergency situations.
We ultimately landed on a modified version of this successful git branching model to handle our releases.
Main development happens in the "master" branch. The types of changes that go directly in master are low-risk changes that likely won't need any tweaking after QA and we're confident will get a thumbs up from the client. Additionally, only complete work should go in master—a work-in-progress or tasks that still need contributions from another team member shouldn't go in master. Commits in master are automatically deployed to our internal integration environment if they pass automated testing, so the PM can always QA the most up-to-date version of master.
When everything that's new in master has been QAed and we're ready for it to be part of the next release, it's time to split off a new release candidate branch from master. We deploy this release branch to a staging environment, where the client can check it out. Any bugs discovered during this period should be fixed directly in the release branch. Once we're clear to go live, we merge the release branch into production.
If we're developing a new feature that will be worked on over time and won't be ready to launch for a while, or if it's something that will need to be touched by multiple people, that will stay in a separate feature branch. We'll deploy that feature branch to a staging environment for client QA, and it won't go in master—and subsequently into a release candidate—until it is complete and has client sign-off.
When we need to deploy something to production right away, and we can’t wait on the next release candidate to either be complete or approved, we’ll do a "hotfix." A developer will create a hotfix branch, which is created off of the production branch rather than master. Once the hotfix is complete, it gets merged into production as well as master, or the existing release candidate if there is one. Hotfixes allow us to react quickly in stop-the-presses situations.