Table of Contents |
---|
Introduction
This page lists three tables with typical tasks that are required for a SIMP release:
...
the list of supported OSs changes
manual tests have been automated
new capabilities must be added to the integration regression test list.
Table Conventions
Unless otherwise noted, the following conventions apply to each table:
Stories are indicated with a
<number>
ID, whereas subtasks to a story are indicated with<parent number>.<child number>
ID.The Blocker field of a story is used to indicate that this story/subtask requires the listed stories/subtasks to be completed before it can be done.
The Story Points field of a subtask may contain an initial guess at the appropriate story points for that subtask. Adjust as needed!
When Y appears in one of the OS fields of a story (e.g. EL8) , that story will be replicated for the permutation noted.
When Y appears in one of the OS fields of a subtask, that subtask will be replicated for the permutation noted within the story.
N, -, and a blank entry are all treated as ‘do not replicate’ indicators.
The Notes field will not be included in the ticket and is intended for maintainers of these tables.
Initial Release Candidate Tickets
The table below lists the typical tasks that are required for the initial release candidate (e.g., ‘Alpha’). The largest number of bugs are found during the initial release candidate. So, some of the tasks may have to be repeated after bugs are fixed and some of the tasks may be blocked until bugs are fixed. The sprint planning for this release should be flexible, accordingly.
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 | Create initial SIMP changelog | Examine changes made to the simp-core project since the previous SIMP release tag (e.g., SIMP-6.5.0-1), as well as changes made to its SIMP dependencies listed in the Puppetfile.pinned. For simp-core changes, examine the following:
For changes for an individual SIMP component, examine changes noted both in its git logs and its CHANGELOG file or | 8 | - | - | - | - | - | - |
| |||||||||||||||||||||||||||||||||||||||||||||||
2.1 | Create changelog | 6 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||||
2.2 | Review changes | 2.1 | 2 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
3 | Update simp-core pre-release tests with release-specific changes | Update simp-core default, ipa, install_from_tar, and simp_lite acceptance test suites for release-specific changes. This includes updating the nodesets and .gitlab-ci.yml for any changes to the supported OSs. | - | 5 | - | - | - | - | - | - | Ideally, this should be done after the initial changelog has been generated, as the changelog informs the work to be done. Tests will be executed for the appropriate OSs permutations in the nodeset, but separate tickets per OS should not be created. | ||||||||||||||||||||||||||||||||||||||||||||||
3.1 | Update tests and nodesets | - | 4 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
3.2 | Review updates | 3.2 | 1 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
4 | Update simp-packer with release-specific changes | Update simp-packer for release-specific changes. Be sure to tag the previous simp-packer version, if the updates will break testing functionality built for the prior SIMP release. | - | 3 | - | - | - | - | - | - | Ideally, this should be done after the initial changelog has been generated, as the changelog informs the work to be done. | ||||||||||||||||||||||||||||||||||||||||||||||
4.1 | Update code and documentation | - | 2 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
4.2 | Review changes | 4.1 | 1 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
5 | Identify release-specific tests and documentation updates | Based on the initial Changelog for the release, identify (1) integration tests that must be done with a fully configured SIMP server and (if necessary) clients and (2) simp-doc documentation that may be affected by the changes. The tests should be tests that are not adequately tested in component acceptance tests. | 2 | 7 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
5.1 | Determine release-specific manual tests | 4 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
5.2 | Determine simp-doc pages that need to be reviewed for accuracy or revised | Identify pages that require an in-depth examination or major revision | 2 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
5.3 | Create tickets for each test and simp-doc page review | 5.1, 5.2 | 1 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
6 | 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 | 3 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
6.1 | Update files and build ISOs for supported OSs | You may need to update package lists for the ISO builds. | - | 2 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
6.2 | Verify acceptance tests | Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed. | 6.1 | 1 | - | - | - | - | - | - | Tests should already been updated for major changes in ID 3 in this table. | ||||||||||||||||||||||||||||||||||||||||||||||
6.3 | Review updates | Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec. | 6.2 | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
7 | Create test ISO, and publish the ISO and its tar file | 6 | 2 | Y | Y | - | - | - | - | This step may actually have to be done several times before we get to an initial release candidate build that can be published. If additional tickets are warranted, they can be created on the fly. | |||||||||||||||||||||||||||||||||||||||||||||||
7.1 | Build ISO | Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com. | - | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
7.2 | Publish artifacts | Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations. | 7.1 | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
8 | Validate ISO by building packer boxes (BIOS and UEFI) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build. | 7 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
8.1 | Build Validate ISO by building packer boxes (BIOS) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.
| - | - | - | - | - | - | 8.2 |
| -7- | Y | -Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||
8.5 | 8. 3 | Build BIOS boot box with FIPS disabled and encrypted disk | - | - | - | - | - | - | - | 8.4 | Build BIOS boot box with FIPS disabled and unencrypted disk | - | - | - | - | - | - | - | Build UEFI boot box with FIPS enabled and encrypted disk2 | Validate ISO by building packer boxes (UEFI) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.
| ||||||||||||||||||||||||||||||||||||
9 | Verify installation from RPMs in tar file | Run simp-core’s install_from_tar test using the tar file generated from an ISO build. | 7 | - | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
89.6 | Build UEFI boot box with FIPS enabled and unencrypted disk | - | - | - | - | - | - | - | 8.7 | Build UEFI boot box with FIPS disabled and encrypted disk | - 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 | - | - | - | -- | |||||||||||||||||||||||||||||||||||||
10 | - | 8.8 | Build UEFI boot box with FIPS disabled and unencrypted disk | - | - | Create upgrade instructions | Document any steps that are needed outside of the generic upgrade instructions. Also look for any unusual messages emitted during RPM upgrade. | 7 | 10 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||
10.1 | Manually execute upgrade with FIPS enabled | 4 | - | 9 | Verify installation from RPMs in tar file | Run simp-core’s install_from_tar test using the tar file generated from an ISO build. | 7- | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||
10.2 | Manually execute upgrade with FIPS disabled | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||||
10.3 | Write upgrade instructions | 4 | - | - | - | - | 9.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- | - | ||||||||||||||||||||||||||||||||||||||||||||
10.4 | Review instructions | Review the instructions for clarity, grammar, spelling, formatting, etc. Verification will be done in a separate ticket | 10.3 | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||
1011 | Create Verify upgrade instructionsDocument any steps | that are needed outside of the generic upgrade instructions. Also look for any unusual messages emitted during RPM upgradeVerify upgrade instructions and make any necessary adjustments to them. | 10 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
1011.1 | Manually execute upgrade with FIPS enabled | 4Execute instructions | 2 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
1011.2 | Manually execute upgrade with FIPS disabledUpdate instructions | 1 | - | - | - | - | - | - | 10.3 | Write upgrade instructions | 4 | - | - | - | - | - | - | 10.4 | Review instructions | Review the instructions for clarity, grammar, spelling, formatting, etc. Verification will be done in a separate ticket | 10.3 | 1 | - | - | - | - | - | - | 11 | Verify upgrade instructions | Verify upgrade instructions and make any necessary adjustments to them. | ||||||||||||||||||||||||||
1012 | Verify PXE boot UEFI | Manually verify clients can PXE boot (UEFI) from a SIMP-managed tftpboot server. https://simp-project.atlassian.net/browse/SIMP-6925 contains links to tickets with descriptions of what others have done previously to test these capabilities.
| 7 | Y | Y | - | - | - | - | 11.1 | Execute instructions | 2 | - | - | - | - | - | - | 11.2 | Update instructions | 1 | - | - | - | - | - | - | 12 | Verify PXE boot UEFI | Manually TODO: Automate these tests | |||||||||||||||||||||||||||
13 | Verify PXE boot BIOS | Manually verify clients can PXE boot (UEFIBIOS) from a SIMP-managed tftpboot server | 7 | Y | Y | - | - | - | - | TODO: Automate these tests | 12.1 |
| - | - | - | - | - | - | 12.2 |
| - | - | - | - | - | - | 12.3 | 12.4 |
| - | - | - | - | - | - |
| - | - | - | - | - | - | 12.5 |
| -7 | Y | Y | - | - | - | - | - | 13 | Verify PXE boot BIOS | Manually verify clients can PXE boot (BIOS) from a SIMP-managed tftpboot serverODO: Finish automation of these tests | ||
14 | Verify non-standard ISO UEFI boot options | Manually verify the choose your own partitions and minimum installation ISO boot options | 7 | Y | Y | - | - | - | - | ODO: Finish automation of these tests | |||||||||||||||||||||||||||||||||||||||||||||||
1314.1 | Verify PXE boot (BIOS) FIPs enabled, disk encrypted, same OS as tftpboot serverthe choose your own partitions option | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||||
1314.2 | Verify PXE boot (BIOS) FIPs enabled, disk unencrypted, same OS as tftpboot serverthe minimum installation option | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||||
13.3 15 | Verify PXE boot (BIOS) FIPs disabled, disk encrypted, same OS as tftpboot server | - | -non-standard ISO BIOS boot options | Manually verify the ‘choose your own partitions' and ‘minimum installation’ ISO boot options | 7 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||
1315.4 Verify PXE boot (BIOS) FIPs disabled, disk unencrypted, same OS as tftpboot server1 | Verify the choose your own partitions option | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||||
1315.5 Verify PXE boot (BIOS) FIPs enabled, disk encrypted, clients from tftpboot server of different OS2 | Verify the minimum installation option | - | - | - | - | - | - | 14 | Verify non-standard ISO UEFI boot options | Manually verify the choose your own partitions and minimum installation ISO boot options | |||||||||||||||||||||||||||||||||||||||||||||||
716 | 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. | 6 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
1416.1 | Verify the choose your own partitions optionDeploy modules to development environments | Update Puppetfiles for development environments and deploy the modules. | - | - | - | - | - | - | |||||||||||||||||||||||||||||||||||||||||||||||||
1416.2 | Verify the minimum installation option | - | Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. | - | - | - | - | - | 15 | Verify non-standard ISO BIOS boot options | Manually verify the ‘choose your own partitions' and ‘minimum installation’ ISO boot options | 7 | Y | Y- | ||||||||||||||||||||||||||||||||||||||||||
16.3 | Examine logs for issues | 16.1, 16.2 | - | - | - | - | - | - | 15.1 | Verify the choose your own partitions option | - | - | |||||||||||||||||||||||||||||||||||||||||||||
17 | Execute misc manual tests | Miscellaneous tests that are not addressed (fully) with automation. | 6 | Y | Y | - | - | - | - | ||||||||||||||||||||||||||||||||||||||||||||||||
1517.21 | Verify the minimum installation option | - | - | - | - | - | - | 16 | 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. | 6 | Y | Y | - | - | - | - | 16.1 | Deploy modules to development environments | Update Puppetfiles for development environments and deploy the modules. | rsyslog local and forwarded logging in simp-core default suite | simp-core's default suite has an extensive rsyslog integration test for local logging and log forwarding that does not use a mock sender ('logger'). Due to rsyslog itself, the rsyslog forwarding verifications have proven to be unreliable. As a stopgap measure, the tests were modified to skip any rsyslog test that fails in the simp-core default suite, in lieu of failing. Unfortunately, this has the potential to hide actual problems. So this ticket is to verify manually that all the failed checks executed in this test actually work. | 1 | - | - | - | - | - | - | ||||||||||||||||||||||||||||
1617.2 | Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. | - | - | - | - | - | - | 16.3 | Examine logs for issues | 16.1, 16.2Verify compliance report in simp-core default suite | Examine the compliance report generated by the simp-core default suite and verify there are no incorrect mappings or unexpected non-compliance. (There will be some non-compliance for overrides that allow the test to run.) | 1 | - | - | - | - | - | - | ||||||||||||||||||||||||||||||||||||||
17 | Execute misc manual tests | Miscellaneous tests that are not addressed (fully) with automation. | 6 | 18 | Verify poss scenario | Manually verify SIMP server and a client operate under the expected security measures when the SIMP server is bootstrapped with the ‘poss’ scenario. | Y | Y | - | - | - | - 17 | Verify using a SIMP server and kickstart client with the same OS. TODO: Automate this test | ||||||||||||||||||||||||||||||||||||||||||||
18.1 | Verify rsyslog local and forwarded logging in simp-core default suite | simp-core's default suite has an extensive rsyslog integration test for local logging and log forwarding that does not use a mock sender ('logger'). Due to rsyslog itself, the rsyslog forwarding verifications have proven to be unreliable. As a stopgap measure, the tests were modified to skip any rsyslog test that fails in the simp-core default suite, in lieu of failing. Unfortunately, this has the potential to hide actual problems. So this ticket is to verify manually that all the failed checks executed in this test actually work. | 1 | - | - | - | - | - | - | 17.2 | Verify compliance report in simp-core default suite | Examine the compliance report generated by the simp-core default suite and verify there are no incorrect mappings or unexpected non-compliance. (There will be some non-compliance for overrides that allow the test to run.) | 1 | - | - | - | - | - | - | 18 | Verify poss scenario | Manually verify SIMP server and a client operate under the expected security measures when the SIMP server is bootstrapped with the ‘poss’ scenario. | Y | Y | - | - | - | - | Verify using a SIMP server and kickstart client with the same OS. TODO: Automate this test | 18.1 | Bootstrap a SIMP server and verify all security measures are enforced. | - | - | - | - | - | - | 18.2 | Kick a client and verify no security measures are enforced |
| - | - | - | - | - | - |
Interim Release Candidate Tickets
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!
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 add those tasks 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 | - | 1Bootstrap a SIMP server and verify all security measures are enforced. | - | - | - | - | - | - | ||||||||||||||||||
18.2 | Kick a client and verify no security measures are enforced |
| - | - | - | - | - | - | ||||||||||||||||||||||||||||||
- | 1.2 | Release components | 1.1 | 219 | Benchmark with SCAP scan | This test is intended to find deficiencies in the enforced DISA STIG security settings for SIMP modules | Y | Y | - | - | - | - | - | - | 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 | |||||||||||||||||||
19.1 | Execute scan and analyze results | Execute the SCAP scan on a FIPS-enabled, disk-encrypted SIMP server packer box for which compliance has been enforced and then analyze the results for any SIMP deficiencies. Looking for system configuration that is not correctly configured for which the compliance report does not indicate an exception. Check may reveal component behavior or component compliance data that needs to be updated. | - | - | - | - | - | - | ||||||||||||||||||||||||||||||
- | 19.2.1 | Update files and build ISOs for supported OSs | You may need to update package lists for the ISO builds. |
| - | 2 | Create tickets for deficiencies | Create tickets for any component deficiencies found. | - | - | - | - | - | - | - | - |
| 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 | - | - | - | - | - | - | 2.3 | Review updates | Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec. |
| 2.2 | 1
Interim Release Candidate Tickets
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!
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 add those tasks 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 | - | - | - | - | - | - | |||||||||||||||||||||||||
| 3 | Create test ISO, and publish the ISO and its tar file | 2 | 2 | Y | Y 1.1 | Identify components to release | - | 1 | - | - | - | - | - | - | ||||||||||||||||||||
31.1 | Build ISO | Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com. | - | 1 2 | Release components | 1.1 | 2 | - | - | - | - | - | - | ||||||||||||||||||||||
3. 2 | Publish artifacts | Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations. | 3.1 | 1Update 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 | - | - | - | - | - | - | ||||||||||||||||||||||
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 | - 2.1 | Update files and build ISOs for supported OSs | You may need to update package lists for the ISO builds. |
| - | 2 | - | - | - | - | - | - |
| |||||||||||
42.2 | Build BIOS boot box with FIPS enabled and unencrypted diskVerify 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 | - | - | - | - | - | - | - | - | 4.3 | Build BIOS boot box with FIPS disabled and encrypted disk | ||||||||||||||||||||
2.3 | Review updates | Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec. |
| 2.2 | 1 | - | - | - | - | - | -- |
| 4.4 | Build BIOS boot box with FIPS disabled and unencrypted disk | |||||||||||||||||||||
- | - | -3 | Create test ISO, and publish the ISO and its tar file | 2 | 2 | Y | Y | - | - | - | - | ||||||||||||||||||||||||
43.5 | Build UEFI boot box with FIPS enabled and encrypted disk | - 1 | Build ISO | Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com. | - | 1 | - | - | - | - | - | - | |||||||||||||||||||||||
43.6 | Build UEFI boot box with FIPS enabled and unencrypted disk | - | 2 | Publish artifacts | Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations. | 3.1 | 1 | - | - | - | - | - | - | ||||||||||||||||||||||
4 .7 | Build UEFI boot box with FIPS disabled and encrypted disk | - | - | - | Validate ISO by building packer boxes (BIOS and UEFI) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build. | 3 | Y | Y | - | - | - | - | ||||||||||||||||||||||
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 | 31 | Validate ISO by building packer boxes (BIOS) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.
| ||||||||||||||||||||
4.2 | Validate ISO by building packer boxes (UEFI) | Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.
| |||||||||||||||||||||||||||||||||
5 | Verify installation from RPMs in tar file | Run simp-core’s install_from_tar test | 2 | - | - | - | - | - | - | - | 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. | 2This 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 | - | - | - | - | ||||||||||||||||||||||||||
7.1 | Deploy modules to development environments | Update Puppetfiles for development environments and deploy the modules.6 | Update Changelog for bug fixes | 2 | 3 | - | - | - | - | - | - | ||||||||||||||||||||||||
7.2 | Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. 6.1 | Identify bug fixes and update changelog | - | 2 | - | - | - | - | - | - | ||||||||||||||||||||||||
7.3 | Examine logs for issues 6.2 | Review changes | 6.1 | 1 | - | - | - | - | - | - | |||||||||||||||||||||||||
8 | Benchmark with SCAP scan | This test is intended to find deficiencies in the enforced DISA STIG security settings for SIMP modules7 | 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 | - | - | - | - | ||||||||||||||||||||||||
8.1 | Execute scan and analyze results | Execute the SCAP scan on a FIPS-enabled, disk-encrypted SIMP server packer box for which compliance has been enforced and then analyze the results for any SIMP deficiencies. Looking for system configuration that is not correctly configured for which the compliance report does not indicate an exception. Check may reveal component behavior or component compliance data that needs to be updated 7.1 | Deploy modules to development environments | Update Puppetfiles for development environments and deploy the modules. | - | - | - | - | - | - | |||||||||||||||||||||||||
87.2 | Create tickets for deficiencies | Create tickets for any component deficiencies found.Install asset RPMs on SIMP server | Install RPMs and watch for any RPM installation error messages. | - | - | - | - | - | - | ||||||||||||||||||||||||||
7.3 | Examine logs for issues | - | - | - | - | - | - |
Release Tickets
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. 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.
...