Content Comparison

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

Y

Y

Y

-

-

-

-

-

-

1-1

Identify components to release

-

1

-

-

-

-

-

-

-

-

-

1-2

Release components

1-1

2

-

-

-

-

-

-

-

-

-

2

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.

simp-core

-

5

Y

N

N

-

-

-

-

-

-

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.

2-1

Update tests and nodesets

-

4

-

-

-

-

-

-

-

-

-

2-2

Review updates

2-1

1

-

-

-

-

-

-

-

-

-

3

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.

simp-packer

-

3

Y

N

N

-

-

-

-

-

-

Ideally, this should be done after the initial changelog has been generated, as the changelog informs the work to be done.

3-1

Update code and documentation

-

2

-

-

-

-

-

-

-

-

-

3-2

Review changes

3-1

1

-

-

-

-

-

-

-

-

-

4

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 and ipa acceptance test suites pass.

simp-core

1

3

Y

Y

Y

-

-

-

-

-

-

For each release candidate (Alpha, RC1, Final), this has a dependency upon the corresponding ticket to release components.

4-1

Update files, build ISOs and execute tests

-

2

-

-

-

-

-

-

-

-

-

4-2

Review updates

4-1

1

-

-

-

-

-

-

-

-

-

5

Create ISOs, validate and publish the ISOs and tar files

simp-core

4

Y

Y

Y

-

-

-

-

-

-

Only the child should be replicated for OSs for which we build an ISO

5-1

Build ISO

-

1

-

-

-

Y

Y

N

N

N

N

5-2

Publish artifacts to simp-project.com

5-1

1

-

-

-

-

-

-

-

-

-

6

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.

5

Y

Y

Y

-

-

-

-

-

-

These are split into a small number of subtasks because they are automated.

6-1

Build packer boxes BIOS boot

Boxes to build: FIPS enabled with encrypted disk, FIPS enabled with unencrypted disk, FIPS disabled with encrypted disk, not FIPS disabled with unencrypted disk

-

-

-

-

Y

Y

N

N

N

N

6-2

Build packer boxes UEFI boot

Boxes to build: FIPS enabled with encrypted disk, FIPS enabled with unencrypted disk, FIPS disabled with encrypted disk, not FIPS disabled with unencrypted disk

-

-

-

-

Y

Y

N

N

N

N

7

Verify installation from RPM (tarball)

Run simp-core’s install_from_tar test

simp-core

5

Y

Y

Y

-

-

-

-

-

-

Only the child should be replicated for OSs for which there is a nodeset for the install_from_tar test

Depending upon changes made from Alpha to RC1 and from RC1 to Final, we may not have to execute these tests with each interim release.

7-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

-

-

-

Y

Y

N

N

N

N

8

Create upgrade instructions

Document any steps that are needed outside of the generic upgrade instructions. 

simp-doc

4

10

Y

N

N

Y

Y

N

N

N

N

First time we deliver an EL8 ISO, we will only have upgrade instructions for EL7

Manual tests for now. Will migrate to simp-integration_test for automated upgrade test.

8-1

Manually execute upgrade with FIPS enabled

4

-

-

-

-

-

-

-

-

-

8-2

Manually execute upgrade with FIPS disabled

1

-

-

-

-

-

-

-

-

-

8-2

Write upgrade instructions

4

-

-

-

-

-

-

-

-

-

8-3

Review instructions

Review the instructions for clarity, grammar, spelling, formatting, etc. Verification will be done in a separate ticket

1

-

-

-

-

-

-

-

-

-

9

Verify upgrade instructions

Verify upgrade instructions and make any necessary adjustments to them.

simp-doc

8

Y

N

N

Y

Y

N

N

N

N

9-1

Execute instructions

2

-

-

-

-

-

-

-

-

-

9-2

Update instructions

1

-

-

-

-

-

-

-

-

-

10

Create initial SIMP changelog

simp-doc

8

Y

N

N

-

-

-

-

-

-

10-1

Create changelog

6

-

-

-

-

-

-

-

-

-

10-2

Review changes

2

-

-

-

-

-

-

-

-

-

11

Identify release-specific tests

Based on the initial Changelog for the release, identify integration tests that must be done with a fully configured SIMP server and (if necessary) clients. These should be tests that are not adequately tested in component acceptance tests.

10

5

Y

N

N

-

-

-

-

-

-

11-1

Determine release-specific manual tests

4

Y

N

N

-

-

-

-

-

-

11-2

Create tickets for each

1

-

-

-

-

-

-

-

-

-

12

Update Changelog for bug fixes

simp-doc

3

N

Y

Y

-

-

-

-

-

-

12-1

Identify bug fixes and update changelog

2

-

-

-

-

-

-

-

-

-

12-2

Review changes

1

-

-

-

-

-

-

-

-

-

13

PXE boot UEFI

Manually verify clients can PXE boot (UEFI) from a SIMP-managed tftpboot server

Y

Y

Y

Y

Y

N

N

N

N

PXE boot UEFI testing is complicated because it cannot be done with VirtualBox. It has to be done with libvirt or real hardware. This needs to be documented in simp-doc (there is a ticket for this!)

These are split into numerous subtasks because they are not yet automated.

13-1

PXE boot (UEFI) FIPs enabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

13-2

PXE boot (UEFI) FIPs enabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

13-3

PXE boot (UEFI) FIPs disabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

13-4

PXE boot (UEFI) FIPs disabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

13-5

PXE boot (UEFI) FIPs enabled, disk encrypted, clients from tftpboot server of different OS

-

-

-

-

-

-

-

-

-

14

PXE boot BIOS

Manually verify clients can PXE boot (BIOS) from a SIMP-managed tftpboot server

Y

Y

Y

Y

Y

N

N

N

N

These are split into numerous subtasks because they are not yet automated.

14-1

PXE boot (BIOS) FIPs enabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

14-2

PXE boot (BIOS) FIPs enabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

14-3

PXE boot (BIOS) FIPs disabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

14-4

PXE boot (BIOS) FIPs disabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

-

-

-

14-5

PXE boot (BIOS) FIPs enabled, disk encrypted, clients from tftpboot server of different OS

-

-

-

-

-

-

-

-

-

15

Verify non-standard ISO UEFI boot options

Manually verify the choose your own partitions and minimum installation ISO boot options

Y

Y

Y

Y

Y

N

N

N

N

15-1

Verify the choose your own partitions option

-

-

-

-

-

-

-

-

-

15-2

Verify the minimum installation option

-

-

-

-

-

-

-

-

-

16

Verify non-standard ISO BIOS boot options

Manually verify the ‘choose your own partitions' and ‘minimum installation’ ISO boot options

Y

Y

Y

Y

Y

N

N

N

N

16-1

Verify the choose your own partitions option

-

-

-

-

-

-

-

-

-

16-2

Verify the minimum installation option

-

-

-

-

-

-

-

-

-

17

Dogfood released modules and RPMs

Use released modules in development environments that exercise as many of the modules as possible

Y

Y

Y

-

-

-

-

-

-

17-1

Deploy modules and RPMs to development environments

Deploy modules to as many OS variants as possible

-

-

-

-

-

-

-

-

-

17-2

Examine logs for issues

-

-

-

-

-

-

-

-

-

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.

18-1

Update the install_from_core_module test with any release-specific changes

18-2

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-4

Publish any missing modules to PuppetForge

18-2

18-5

Execute the install_from_core_module test

19

Announce release

20

Verify RPMs have been uploaded simp-project.com

20-1

21

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.

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 each major section of the documentation, an will need to be updated accordingly when the docs structure changes.

21-1

Review ‘Quick Start’

Review and update as necessary

21-3

Review ‘Getting Started’

Review and update as necessary

21-4

Review ‘User Guide’

Review and update as necessary

21-5

Review ‘HOWTO’

Review and update as necessary

21-6

Review ‘FAQ’

Review and update as necessary

21-7

Review ‘Help’ and ‘Contact’ sections

Review and update as necessary

21-8

Review ‘Glossary of Terms’

Review and update as necessary

22

Review security documentation

General review of security-related documentation. Intent is to make sure the information is current 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 each major section 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

22-2

Review ‘Security Control Mapping’

Review and update as necessary

22-3

Review ‘Vulnerability Supplement’

Review and update as necessary