Page History
Doctrines
When fixing an issue for security-related patches in an open source project we follow these procedures:
- Create a new issue in DSEC project, describing the issue with all the required details.
- Create a ticket in your application's project(e.g. CMR, MMT, EDSC). The title should be "Fix the issue in DSEC-X" where "X" is the ticket number generated in step 1.
- Do not put any details in the project ticket's description or acceptance criteria other than "Fix the issue listed in DSEC-X"
- Link the ticket to the DSEC ticket with a status of "resolves", e.g. MMT-1282 resolves DSEC-14 (These numbers are made up, it's just an example)
- Contact your friendly security team member for severity and priority for work.
- Coordinate with your Dev Team Lead and Scrum Master to discuss priority.
- Once approved for work, reference the project ticket and not the DSEC ticket.
- Do not reference 'security' or any other terms in your repository fix. This is because it will be published to the public repository before it has actually been applied to the environments.
- Backport to any required branches and prepare releases.
- Upon completion of the work contact your local friendly Product Owner/OPS Designated person for deployment.
When deploying a release we apply the following doctrines:
- We expect the development group/product owner to create the release
- We will only deploy a release to an environment if that release has successfully been applied to the prior environment.
- PROD release will only occur if it has successfully applied to UAT
- UAT release will only occur if it has successfully applied to SIT
- When selecting a minor release for an environment that release must match the current minor release of the prior environment.
- If 1.18.4 is in UAT and we wish to promote 1.18 to PROD then we must apply 1.18.4 to PROD
- If 1.19.2 is in SIT and we wish to promote 1.19 to UAT then we must apply 1.19.2 to UAT
- When applying a minor release to SIT we must apply that same minor release to UAT once SIT has been verified.
- If we apply 1.19.2 to SIT successfully we must then apply 1.19.2 to UAT as soon as possible.
- All of the tickets associated with the release have a FixVersion attached to them, and is reviewed before deployment.
- All issues should be in the "Verified Internal" or higher state before deployment to PROD, excepting those tickets that can ONLY be applied to PROD. A note should be included in the ticket.
A 'successful' release is defined as follows,
- The deployment is successful
- Sanity check is successful
- If the release has an issue that can be tested in the environment it must be tested successfully.
In the event a change needs to be reverted:
- Create a new issue for the reversion and give it a FixVersion of a +1 minor version. (e.g. reverting a change in 1.102.1, the reversion should be fixVersion 1.102.2)
- Revert the release, and reference the new ticket # in the commit.
- Follow normal release processes with the reverted code.
Exceptions
- Emergency releases
- In rare cases, we will have a situation where a problem in PROD will cause severe service degradation. In those cases, with the agreement of the DEV and OPS leadsproduct owner, a release can be applied directly to PROD.
- PROD/UAT fixes
- PROD is always one major release behind UAT. If a fix is applied to 1.19 in the form of 1.19.2 then that would be applied to SIT and UAT. But PROD is on 1.18.4 so a new release would be created for PROD (1.18.5) and deployed directly without testing in SIT and UAT
Minor Release process
This process is triggered every time a development sprint ends.
Step no. | Step description | Further documentation | Responsibility |
---|---|---|---|
1 | Complete sprint |
| DEV |
2 | Produce release notes page | In order to ensure that deployment occurs correctly, any pre-requisites or special instructions for a release need to be captured. An example is here - CMR Version 1.60 Notable changes is important for our DSR presentations so provide it. | DEV |
3 | Create minor release |
| DEV |
4 | Create patch release branch in git | Earthdata Bit Bucket
NASA Github
| DEV |
5 | Deploy to SIT - unless continuous build in place | On the Monday after the Friday sprint closure, Deploy minor release to SIT environment via Bamboo | OPS |
6 | Create verification Kanban board |
| TEST |
7 | Deploy to UAT | On the Wednesday after SIT deployment, if SIT deployment was successful, Deploy minor release to UAT environment via Bamboo | OPS |
8 | Verify release issues | Using sprint demos and issue test instructions, verify all issues in the verification Kanban board. Confirm all issues in the release are in the Verified Internal State or higher. | TEST |
9 | Deploy to Production | On the second Wednesday after UAT deployment if all issues were verified, Deploy major release to PROD environment via Bamboo | OPS |
10 | Delete maintenance branch | Once a release has been superceeded in PROD the maintenance branch is no longer required. For, example, when 1.02 is deployed to PROD, the maintenance branch 1.01.x can and should be deleted. Earthdata Bit Bucket
NASA Github
|
Patch Release process
This process is triggered every time an issue is detected that needs to be pushed to an environment outside of the sprint process.
For example,
- Showstopper issue detected
- Failed verification in UAT
Step no. | Step description | Further documentation | Responsibility |
---|---|---|---|
1 | Create git feature branch on master | git checkout -b <JIRA issue number> | DEV |
2 | Complete fix | Ensure all tests pass | DEV |
3 | Push to master | git push -u origin HEAD | DEV |
4 | Cherry pick from master to patch release branch |
| DEV |
5 | Create patch release |
| DEV |
6 | Create tag in repository |
| DEV |
7 | Create patch release branch in bamboo |
| OPS |
8 | Deploy to appropriate environments | Deploy minor release to SIT|UAT|PROD environment via Bamboo | |
9 | Verify patch release | OPS |
Hide comments |
---|