Includes:
Code for Content Localization solution is delivered and released in stages where it undergoes different types of automated checks driven by GitHub Actions workflows. The stages are: Pre-commit → PR → Nightly → Release. The objective and configuration of each stage is summarized in the table below:
|
|
Pre-commit |
Pull-request (PR) |
Nightly |
Release |
|
Branch |
Feature |
development |
development |
development → PR → main |
|
Trigger |
Push to remote (public) repository |
Pull request |
Nightly workflow |
Release workflow |
|
AWS region |
us-west-2 |
us-west-2 |
us-west-2 |
all supported regions for solution |
|
Deployment modes |
N/A |
New deploy |
New Deploy and Update |
New deploy and update |
|
Objective |
Prevent sensitive data or unliscensed third party code from being commited to the public repository |
The PR code is "clean" and builds successfully. Unit tests are passing. Deployment is successful. |
Deployment is successful on development branch against MIE for update deploy. All scans are passing. Unit, integration and end-to-end tests are passing. |
Deployment is successful on release branch against latest MIE release for new deploy and update of previous release. All scans are passing. Integration tests are passing. |
|
Actions performed by stage |
|
|
|
|
|
|
Pre-commit |
Pull-request (PR) |
Nightly |
Release |
|
build |
yes |
yes |
yes |
yes |
|
third party scan |
yes |
yes |
yes |
yes |
|
sensitive data scan |
yes |
yes |
yes |
yes |
|
quality scan |
yes |
yes |
yes |
yes |
|
unit test |
yes |
yes |
yes |
yes |
|
deploy test |
|
new |
new and update* |
new and update |
|
integration test |
|
|
yes |
yes |
|
end to end test |
|
|
yes |
no |
|
publish code packages and label release |
|
|
|
yes |
|
publish solution |
|
|
|
|
*When update deployment is failing on the Nightly test runs, it may mean there is a breaking change in the current development code base and the next release will need to be a major version. It is not necessarily considered a failure, but surfaces a significant finding. The team will need to decide the course of action for advising users under previous versions for using the new release.
Pre-commit stage
The objective of the Pre-commit stage of testing is to prevent sensitive data or unlicensed third party code from being committed to the public repository. Developers commit feature work to the remote (public) instance of the repository throughout a development sprint using feature branches. Work is committed to feature branches that are not yet integrated with the shared code base on the development and main branches. Even though these changes are not integrated to the shared code base, pushing a feature branch to the public repository is "publishing" the code in the sense that the work in progress is viewable and consumable by everyone on GitHub. We need to ensure that this steps doesn't inadvertently expose the GitHub community to intellectual property or security risks.
Pull-request (PR) stage
The objective of the Pull-request (PR) stage is to ensure the code from a feature branch that is being integrated into the shared code base under development doesn’t introduce instability into the shared code base. At a minimum, the code is "clean", builds and deploys successfully and unit tests are passing. Developers integrate their feature work to the shared code base by creating a PR on the development branch. The PR must pass the automated PR tests as well as being reviewed by a committer for the project. PR testing should support the code review process and help ensure the stability of the code base. It is important to maintain stability of the builds and deployments as problems at this stage can impact the productivity of the entire development team.
Nightly stage
Some testing may not be feasible for every PR due to time and resource constraints. A nightly test run is used to perform longer running tests on the shared code base to ensure ongoing stability.
Release stage
The objective of the Release stage is to test and publish new release of Content Localization on GitHub. Committers for the project periodically create releases with bug fixes and new features. The release workflow includes:
- creating a release branch from development branch
- building deployment packages that will be hosted for the release
- updating one-click deploy button(s) in the README.md to point to the release deployment package
- testing the deployment packages
- pushing the release to the main branch
- labelling the release.