Add Release Checklist article to "Approach" section #731
Conversation
kewlguy781
force-pushed
the
jon-release-checklist
branch
from
f21c927
to
0c356db
Compare
Co-authored-by: Alex Soble <[email protected]>
Co-authored-by: Alex Soble <[email protected]>
|
@kingcomma Its ready for your review. (see preview link Alex S. posted here). Let me know if it look good then I ll move PR out of draft. |
|
@kingcomma -- marked as ready for your review! Thank you! |
Co-authored-by: Michael King <[email protected]>
|
@alexbielen I'm marking this as ready for engineering director review! |
| Here are some key components typically included in a release checklist: | ||
|
|
||
| 1. **Functional Testing**: Verify that all new features, enhancements, or bug fixes work as expected according to the defined requirements and specifications. This also includes user experience/user acceptance testing. | ||
|
|
||
| 2. **Integration Testing**: Ensure that the software integrates correctly with other systems or components it interacts with, such as databases, APIs, or third-party services. | ||
|
|
||
| 3. **Performance Testing**: Check the software's performance metrics (e.g., response times, throughput) to ensure it meets performance requirements under expected load conditions. | ||
|
|
||
| 4. **Security Testing**: Validate that security measures (e.g., authentication, authorization, data encryption) are in place and functioning correctly to protect against vulnerabilities. | ||
|
|
||
| 5. **Deployment Readiness**: Ensure that deployment packages are prepared, deployment scripts are tested, and necessary configurations (e.g., environment variables, server settings) are set correctly for the production environment. |
There was a problem hiding this comment.
@kewlguy781 -- we talked about this in our 1:1 -- what are your thoughts on how these items on a release checklist fit into a project that's using CI/CD and DevOps?
Taking the security testing item as an example. I'd expect any 18F software project near release to be running automated security scans on a regular basis (e.g. on every PR) and running automated tests on every commit.
Are there specific security-related testing steps that come to mind as important to call out in a release checklist -- above and beyond the security testing that happens on every commit or every PR under continuous integration?
There was a problem hiding this comment.
The Launch guide does cover that. I am not sure if we want to repeat these that are already mentioned in the launch guide. Thought?
There was a problem hiding this comment.
Which section(s) of the launch guide?
To my understanding, the launch guide is TTS-only whereas this resource will be public. So I think the Release Checklist article will need to stand on its own -- we shouldn't assume anyone reading Release Checklist will also be able to read the Launch guide.
|
|
||
| 7. **Backup and Rollback Plans**: Verify that backup procedures are in place and tested, and that rollback procedures are documented and ready to be executed if needed. | ||
|
|
||
| 8. **Compliance Checks**: Ensure that the release complies with legal, regulatory, and organizational policies (e.g., licensing, data protection). Your system may need a new ATO (Authority to Operate) or to be covered under an existing ATO. |
There was a problem hiding this comment.
@kewlguy781 Suggest revising the language around ATO here. A software release shouldn't require a new ATO unless it totally changes the system architecture.
There was a problem hiding this comment.
I think the relevant concepts are covered here in Lindsay Young's Introduction to ATOs piece on digital.gov -- https://digital.gov/resources/an-introduction-to-ato/
As the system changes, the system owner needs to work with the security team to update the SSPP documentation. This process is called a Significant Change Request (SCR). For example, if your website is adding a new service like emailing updates to users, this adds new technical tools and data to your system; you’ll need to go through the SCR process to gain permission.
There was a problem hiding this comment.
added link to ATO
There was a problem hiding this comment.
Thanks for adding the link @kewlguy781!
I still have a concern here about saying releases will require new ATOs -- in general they shouldn't, unless the release introduces a totally new system architecture. Let's talk about this in our 1:1 this week.
| ### Resources: | ||
| [18F Launch Preparation](https://docs.google.com/document/d/1gJcvQ-o0DMEUY3m19KGPw8y6qFPvdX7FWC6OSlURRmM/edit) | ||
|
|
||
| [Examples of other project release checklists](https://drive.google.com/drive/folders/1zpBpZ9OjfHDuCJIrF8Uqzuu7VsdZ1s8-) |
There was a problem hiding this comment.
@kewlguy781 Suggestion -- link directly to an example checklist that models the structure you lay out in this article.
The Examples link goes to a folder that contains a variety of documents and checklists -- as a reader it's hard to know which I should look at first and which one best models the structure you lay out here.
|
@kewlguy781 amazing work, thank you for writing this up! I'd like to spend some time reviewing now that I'm back. Will comment here with any questions or thoughts! |
| 4. **Communication and Collaboration**: The checklist serves as a communication tool between different teams involved in the release process (development, testing, operations, etc.). It helps in aligning everyone on what needs to be done and ensures that all stakeholders are on the same page. | ||
|
|
||
| 5. **Documentation**: It serves as a record of what has been tested and verified before the release. This documentation is valuable for audit purposes, troubleshooting post-release issues, and for future reference. | ||
|
|
There was a problem hiding this comment.
These two (Communication/collaboration and Documentation) feel like the pieces that make a release checklist valuable in conjunction with more developer-focused tools like good integration/unit tests and CI/CD pipelines. A checklist like this helps keep a team on the same page with regards to what's been done and what still needs to be addressed. I think there's an opportunity to use this page's introductory paragraph to frame the importance of the communication/documentation part of this.
|
|
||
|
|
||
| The release checklist is typically tailored to the specific needs and processes of the agency, the department, or project. It is often managed and maintained by a project manager, release manager or a release team to ensure consistency and thoroughness across releases. By following a release checklist, teams can reduce the risk of releasing faulty or incomplete software, improve communication and collaboration among team members, and enhance overall confidence in the software release process. | ||
|
|
There was a problem hiding this comment.
It is often managed and maintained by a project manager, release manager or a release team to ensure consistency and thoroughness across releases.
I think this should go in the intro. Perhaps we need a couple of sentences about how the team uses the checklist?
|
Closing this PR as we will do a new PR for the revamped doc based on feedback from people. |
Changes proposed in this pull request:
Added Release Checklist article to approach section.
security considerations
There are some links to Google Docs/Drive, but requires Gauth with GSA account.