Releases
Software is rarely unchanging; it is important to have a clear strategy when pushing out new versions.
Release management refers to how software is built, tested, and deployed within an organization. Having a well-understood and agreed-upon philosophy to underpin your releases is key to ensuring correct and safe coding practices.
Generally, a software release will have several phases, some of which may overlap:
- An analysis phase, when stakeholders agree what features are to be prioritised for the next release.
- A design phase, when product and engineering teams decide how these features are to be implemented.
- A development phase, when code gets written.
- A testing phase, where quality assurance testing is performed on the release candidate code.
When all phases are complete, the new features can be released to the world, and the cycle begins again.
There are competing philosophies on how best to structure release cycles, how often they should happen, and how long each phase should last. Approaches vary significantly depending on the size of the development team, the complexity of the product, the need for innovation vs. the risk of breaking existing features, and how safety-critical the software being produced is. There are a number of best practices recommended by all software development methodologies, which you should make sure to practice:
- Agree on a feature set at the start of a release cycle.
- Have clearly defined roles about who owns each feature, who is responsible for design, development and testing, and who signs off.
- Communicate requirements clearly and early, and document them using an issue tracker.
- Use source control and an agreed branching strategy. Tie code check-ins back to issues in your issue tracker.
- Be transparent about release dates, and be realistic about how much can get done in a given code cycle. Agree as a team to slip features or dates, if there is not adequate time.
- Ensure your team shares a common vision for your software, and understands why features are important. Practice frequent communication between team-members to ensure fewer surprises at the end of the release cycle.
- Limit scope creep.
- Test early, and test often. In addition to manual testing, write unit tests to catch edge cases and ensure no regressions. Use continuous integration so the status of the code branch is known at all times. Make sure developers do not push code until they are reasonably sure it is bug-free.
Release Process
Your release process should be agreed-upon and documented clearly. Make sure you follow these best practices:
- Before releasing to your production environment, ensure to thoroughly test your software in a test environment that resembles production as much as is feasibly possible.
- Agree on a release window ahead of time, and define responsibilities. Make sure the release is performed with temporary permissions, by named individuals, who have those permissions revoked thereafter.
- Ensure you have a plan to rollback if the release fails in some fashion.
- The code released to production should be the same as was previously tested in a pre-production environment -- only configuration information should differ.
- Once code has been deployed and all system upgrades have been performed, undertake a thorough post-release sanity check. Test all new features released and validate that existing features still work.
- Ensure any discrepancies or errors are diagnosed, or noted for explanation if they are not judged to be significant.
- End the release process with a final sign-off if stakeholders agree everything looks good, or a rollback followed by a regression test if things went wrong.