...
The table below lists the typical tasks that are required for the interim release candidates (e.g., ‘Beta’, ‘RC1’). Fewer and fewer bugs are found with each interim release candidate. Any manual integration testing should be targeted to verification of the bug fixes, whereas as many automated integration tests as resources allow should be executed! Also, depending
Depending upon the bug fixes included in this release candidate, tests identified in the initial release tickets table may need to be re-executed. So, be sure to copy in add those tasks into to your copy of this table before generating tickets.
ID | Ticket Summary (< 100 chars) | Description | Component | Blockers | Story Points | EL7 | EL8 | OEL7 | OEL8 | RH7 | RH8 | Notes |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Release Components | Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html | - | 3 | - | - | - | - | - | - | ||
1.1 | Identify components to release | - | 1 | - | - | - | - | - | - | |||
1.2 | Release components | 1.1 | 2 | - | - | - | - | - | - | |||
2 | Update simp-core with released components | Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass. You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab. | 1 | 3 | - | - | - | - | - | - | ||
2.1 | Update files and build ISOs for supported OSs | You may need to update package lists for the ISO builds. |
| - | 2 | - | - | - | - | - | - |
|
2.2 | Verify acceptance tests | Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed. |
| 2.1 | 1 | - | - | - | - | - | -Tests should already been updated for major changes. | |
2.3 | Review updates |
|
| 2.2 | 1 | - | - | - | - | - | - |
|
3 | Create test ISO, and publish the ISO and its tar file | 2 | 2 | Y | Y | - | - | - | - | |||
3.1 | Build ISO | Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com. | - | 1 | - | - | - | - | - | - | ||
3.2 | Publish artifacts | Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations. | 3.1 | 1 | - | - | - | - | - | - | ||
4 | Validate ISO by building packer boxes | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build. | 3 | Y | Y | - | - | - | - | |||
4.1 | Build BIOS boot box with FIPS enabled and encrypted disk | - | - | - | - | - | - | - | ||||
4.2 | Build BIOS boot box with FIPS enabled and unencrypted disk | - | - | - | - | - | - | - | ||||
4.3 | Build BIOS boot box with FIPS disabled and encrypted disk | - | - | - | - | - | - | - | ||||
4.4 | Build BIOS boot box with FIPS disabled and unencrypted disk | - | - | - | - | - | - | - | ||||
4.5 | Build UEFI boot box with FIPS enabled and encrypted disk | - | - | - | - | - | - | - | ||||
4.6 | Build UEFI boot box with FIPS enabled and unencrypted disk | - | - | - | - | - | - | - | ||||
4.7 | Build UEFI boot box with FIPS disabled and encrypted disk | - | - | - | - | - | - | - | ||||
4.8 | Build UEFI boot box with FIPS disabled and unencrypted disk | - | - | - | - | - | - | - | ||||
5 | Verify installation from RPMs in tar file | Run simp-core’s install_from_tar test | 2 | - | - | - | - | - | - | - | This test can be omitted if there are no changes to component packaging since the previous candidate. Component behavior is already tested by the simp-core default suite with each simp-core check-in. | |
5.1 | Execute test | See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md for description of environment variables that can be set to point to the tar file | 1 | Y | Y | - | - | - | - | |||
6 | Update Changelog for bug fixes | 2 | 3 | - | - | - | - | - | - | |||
6.1 | Identify bug fixes and update changelog | - | 2 | - | - | - | - | - | - | |||
6.2 | Review changes | 6.1 | 1 | - | - | - | - | - | - | |||
7 | Dogfood released modules and assets | Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers. | 2 | Y | Y | - | - | - | - | |||
7.1 | Deploy modules to development environments | Update Puppetfiles for development environments and deploy the modules. | - | - | - | - | - | - | ||||
7.2 | Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. | - | - | - | - | - | - | ||||
7.3 | Examine logs for issues | - | - | - | - | - | - |
...
The table below lists the typical tasks that are required for the final release. By the time we get to this phase of the release process, there are few, if any bugs found, and very little manual testing is required. There are quite a number of documentation review tickets, however.
...
ID
...
Ticket Summary (< 100 chars)
...
Description
...
Component
...
Blockers
...
Story Points
...
EL7
...
EL8
...
OEL7
...
OEL8
...
RH7
...
RH8
...
Notes
...
1
...
Release Components
Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html
...
The user documentation tickets are required for each major release, nice-to-have for each minor release, and not necessary for each patch release. They will need to be updated each time the user documentation undergoes structural changes.
As with interim releases, depending upon the bug fixes included in this release candidate, tests identified in the initial release tickets table may need to be re-executed. So, be sure to copy in those tasks into your copy of this table before generating tickets.
ID | Ticket Summary (< 100 chars) | Description | Component | Blockers | Story Points | EL7 | EL8 | OEL7 | OEL8 | RH7 | RH8 | Notes | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Release Components | Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html NOTE: This excludes simp-doc, which is addressed a separate ticket after all documentation updates have been completed. | - | 3 | - | - | - | - | - | - | ||||||
1.1 | Identify components to release | - | 1 | - | - | - | - | - | - | |||||||
1.2 | Release components | 1.1 | 2 | - | - | - | - | - | - | |||||||
2 | Update simp-core with released components | Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass. You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab. All components in the Puppetfile.pinned except simp-doc should be referencing a GitHub tag. simp-doc is addressed in its own ticket. | 1 | 3 | - | - | - | - | - | - | ||||||
2.1.1 | Identify components to release | - | Update files and build ISOs for supported OSs | You may need to update package lists for the ISO builds. |
| - | 2 | - | - | - | - | - | - |
| ||
2.2 | Verify acceptance tests | Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed. |
| 2.1 | 1 | - | - | - | - | - | - | |||||
1.2 | Release components | 1.1 | 2 | 2.3 | Review updates |
|
| 2.2 | 1 | - | - | - | - | - | - | |
123 | Update Changelog for bug fixes | 12 | 3 | - | - | - | - | - | - | |||||||
123.1 | Identify bug fixes and update changelog | - | 2 | - | - | - | - | - | - | |||||||
123.2 | Review changes | 123.1 | 1 | - | - | - | - | - | - | |||||||
214 | Review user documentation | General review of user documentation. Intent is to make sure the information is current and intelligible. Does not include ‘Changelog’, ‘Contributing to SIMP’, ‘Security Concept of Operations’, ‘Security Control Mapping’, ‘Vulnerability Supplement’ and ‘License’ sections, some of which are covered by other tickets. | 2 | - | - | - | - | - | - | This is required for each major release, nice-to-have for each minor release, and not necessary for each patch release. Subtasks should correspond to major sections of the documentation, an will need to be updated accordingly when the docs structure changes. | ||||||
214.1 | Review ‘Quick Start’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
214.3 | Review ‘Getting Started’ | Review and update as necessary | Review ‘Getting Started’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||
214.4 | Review ‘User Guide’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
214.5 | Review ‘HOWTO’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
214.6 | Review ‘FAQ’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
214.7 | Review ‘Help’ and ‘Contact’ sectionsReview and update as necessarysections | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
214.8 | Review ‘Glossary of Terms’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
22 | Review security documentation | General review of security-related documentation. Intent This is a general review to make sure the information is current accurate and intelligible. | - | - | - | - | - | - | This is required for each major release, nice-to-have for each minor release, and not necessary for each patch release. Subtasks should correspond to major sections of the documentation, an will need to be updated accordingly when the docs structure changes. | |||||||
22.1 | Review ‘Security Concept of Operations’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
22.2 | Review ‘Security Control Mapping’ | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
22.3 | Review ‘Vulnerability Supplement’Review and update as necessary | Review and update as necessary. This is a general review to make sure the information is accurate and intelligible. | - | - | - | - | - | - | ||||||||
23 | Finalize simp-doc | |||||||||||||||
23.1 | Remove any reference to release candidates | |||||||||||||||
23.2 | Release | |||||||||||||||
4 | Update simp-core with released components, including simp-doc and verify versions | Update simp-core files ( Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass. You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab. All components in the Puppetfile.pinned should be referencing a GitHub tag. | 1 | 3 | - | - | - | - | - | - | ||||||
4.1 | Update files , and build ISOs and execute tests | - | 2 | - | - | - | - | - | - | |||||||
4.2 | Review updatesVerify versions | Make sure there are no version discrepancies in the Puppetfile.pinned, metadata.json and simp.spec files. | 4.1 | 1 | - | - | - | - | - | - | ||||||
18 | Verify simp/simp_core meta module | Verify that the simp/simp_core meta module has appropriate dependencies and its dependencies have all been published to PuppetForge by running the install_from_core_module test suite. | 4 | |||||||||||||
18.1 | Execute check for PuppetForge publication | Execute ‘bundle exec rake puppetfile:check’ and examine output to identify any modules that have not been published to PuppetForge | ||||||||||||||
18.2 | Publish any missing modules to PuppetForge | |||||||||||||||
18.3 | Update the install_from_core_module test with any release-specific changes | |||||||||||||||
18.4 | Execute the install_from_core_module test | |||||||||||||||
17 | Dogfood released modules and assets | Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers. | 5 | Y | Y | - | - | - | - | |||||||
17.1 | Deploy modules to development environments | Update Puppetfiles for development environments and deploy the modules. | - | - | - | - | - | - | ||||||||
17.2 | Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. | - | - | - | - | - | - | ||||||||
17.3 | Examine logs for issues | - | - | - | - | - | - | |||||||||
5 | Create final ISO, verify with simp-packer, and publish the ISOs and their tar files | This is the final build and spot check via simp-packer. | 4 | Y | Y | - | - | - | - | |||||||
5.1 | Build ISO | Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com. | - | 1 | - | - | - | - | - | - | ||||||
5.2 | Build BIOS boot box with FIPS enabled and encrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.3 | Build BIOS boot box with FIPS enabled and unencrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.4 | Build BIOS boot box with FIPS disabled and encrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.5 | Build BIOS boot box with FIPS disabled and unencrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.6 | Build UEFI boot box with FIPS enabled and encrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.7 | Build UEFI boot box with FIPS enabled and unencrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.8 | Build UEFI boot box with FIPS disabled and encrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.9 | Build UEFI boot box with FIPS disabled and unencrypted disk | 5.1 | - | - | - | - | - | - | ||||||||
5.10 | Publish artifacts | Final artifacts that have passed simp-packer validation are published to official release folders at simp-project.com. | 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9 | 1 | - | - | - | - | - | - | ||||||
19 | Announce release | 5 | - | - | - | - | - | - | ||||||||
20 | Post-release: Verify RPM publication | Verify RPMs have been uploaded to simp-project.com. This includes Puppet module RPMs, SIMP application RPMs, and any other auxiliary, application RPMs. | ||||||||||||||
20.1 | Verify Puppet module RPMs have been published | Execute ‘bundle exec rake puppetfile:check’ and examine output to identify any modules that have not been published to simp-project.com. | ||||||||||||||
20.2 | Verify other RPMs have been published | Run the install_from_rpm test. See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md . If a nodeset for the OS under test does not exist, create it. | Y | Y | ||||||||||||
20.3 | Publish any missing RPMs | |||||||||||||||
...