Writing code is great, but it doesn't mean much if it doesn't make it to production. There is tremendous satisfaction in knowing that your work is "live" and impacting people's lives.
With such power to impact people's lives comes great responsibility. We owe it to our clients and the people who depend on us to produce reliable products. That means not only writing robust code that is well tested, but also ensuring the release is performed well with few hiccups and little downtime.
+---------------------------+---------------------------------------------------------------+ | Term | Description | +---------------------------+---------------------------------------------------------------+ | Clients | People who pay us money and/or external and internal | | | stakeholders within the organization. The Project Manager | | | should be the one who knows who is considered a "Client." | +---------------------------+---------------------------------------------------------------+ | Developers | Staff who are writing the code for the application(s). | +---------------------------+---------------------------------------------------------------+ | Operations | IT Staff who are responsible for managing the computing | | | resources which run the application(s). | +---------------------------+---------------------------------------------------------------+ | Feature Freeze | A date which dictates that no more features are to be | | | developed. Only bug fixes are worked on and merged. | +---------------------------+---------------------------------------------------------------+ | Launch Day | The day that the latest code is deployed to production. Often | | | involves some system downtime. | +---------------------------+---------------------------------------------------------------+ | Go/No-Go Decision Meeting | This is the decision point that determines whether to | | | "launch" the latest code on Launch Day. All parties involved, | | | including Clients, Developers, and Operations should | | | determine whether a "launch" is ready to "GO" before | | | deploying the release. | +---------------------------+---------------------------------------------------------------+ | Launch Retrospective | This meeting is meant to facilitate a nonblaming discussion | | | to identify root causes for issues that cropped up leading up | | | to and during the launch. Notes should be taken and learnings | | | should be shared with the team broadly. | +---------------------------+---------------------------------------------------------------+ | Release Branch | The branch which is cut from `development` | | | (e.g. `prod-- - `), and then subsequently | | | merged into `main` once testing is complete. | +---------------------------+---------------------------------------------------------------+ | Release Tag | A commit that has been `git tag`'d, preventing any other | | | commits and also making it easier to "revert" back to a | | | previous `tag`. | +---------------------------+---------------------------------------------------------------+ | Unit Tests | Tests that cover a small section of code. Unit tests are run | | | fast and frequently, often while you are writing code. | +---------------------------+---------------------------------------------------------------+ | Integration Tests | Tests that cover multiple systems that rely on one | | | another. These may include mocking a particular system | | | (e.g. mocking API endpoints to test a Frontend | | | component). These tests run are run more infrequently, but | | | are still run before merging code upstream from a feature | | | branch to `development` or `main`. | +---------------------------+---------------------------------------------------------------+ | System Tests | Tests of the entire system. Often this must be done manually, | | | but tools like Cypress (https://www.cypress.io/) can enable | | | browser-based testing to become fully automated. | +---------------------------+---------------------------------------------------------------+
Here is a checklist for organizing your next release:
0. Invite Clients, Operations, and Developers to a meeting to discuss the Release Schedule.
1. Set a target date for the Launch Day.
2. Set aside a Testing Period. This should be 2-4 weeks for major features and refactors and at least a week for bugs.
3. Set a date for a Feature Freeze. This should coincide with the start of the Testing Period.
4. Set a target date to deploy to Development. (See the section on "Deploying to Development" for more information.)
5. Set a meeting for the "Go/No-Go" decision point. This meeting should be 2-3 days ahead of the Launch Day and should consist of Clients, Developers, and Operations.
5. Communicate to the Clients, Developers, and Operations staff about the release schedule, including the Testing period, Feature Freeze deadline, the date code will be deployed to Development, the Go/No-Go Decision Meeting, and the Launch Day.
As timelines and priorities shift, Developers should stay vigilant about meeting the Feature Freeze deadline. When features are not ready or are still in the works, it is best to cut the feature from the release rather than continue to work on it during the Feature Freeze. The next Launch Day is just around the corner.
As features and bugs are developed, ensure each Pull Request includes manual testing steps that should be done during the Testing Period and that relevant Unit and Integration tests are written. Remember, the more automated Unit & Integration tests, the less manual testing that will need to be performed to verify the system is working properly.
Once the Feature Freeze deadline has come, it is time to deploy the latest code to development for testing. Keep a notepad to track the commands used to deploy. When you run into issues, it's bound to also happen on Production. Being able to refer to your notes deploying on Production means you won't have to "figure it out" a second time.
Be sure to update any documentation on Dev Docs to match the latest deploy steps once you have finished.
A successful testing period covers the breadth of features and bugs that have been worked on. To do so:
1. Pull out the testing steps from the most recent PR's into a Testing Script Google Sheet. See:
2. Send out an email to Clients with the Testing Script and ask them to assist in performing testing and validation of any new features or bug fixes.
3. Developers should check on the Testing Script often to see if any bugs or issues have been reported. Ask for thorough reproduction steps when a bug is being reported.
4. As bugs come in, work them in order of "show-stoppers" and re-deploy once fixes have been merged. Include in your pull request title `"Bugfix for Release