mirror of
https://github.com/Alfresco/alfresco-transform-core.git
synced 2025-05-19 17:14:47 +00:00
ATS-628: Update release process
This commit is contained in:
Cezar.Leahu
CezarLeahu
parent
4e5915b941
commit
d863b63e4e
@ -19,8 +19,7 @@ branches:
|
||||
only:
|
||||
- master
|
||||
- /^SP\/.+$/
|
||||
- release
|
||||
- /^release\/SP\/.+$/
|
||||
- /^HF\/.+$/
|
||||
- company_release
|
||||
- /^ATS-.*$/
|
||||
|
||||
@ -31,7 +30,7 @@ stages:
|
||||
|
||||
jobs:
|
||||
include:
|
||||
- name: "Build"
|
||||
- name: "Build + Tests"
|
||||
stage: build
|
||||
if: branch NOT IN (company_release)
|
||||
before_install: bash _ci/init.sh
|
||||
@ -46,7 +45,7 @@ jobs:
|
||||
|
||||
- name: "Release"
|
||||
stage: release
|
||||
if: branch = release OR branch =~ /^release\/SP\/.+$/
|
||||
if: commit_message ~= /\[trigger release\]/ AND branch ~= /^(master|SP\/.+|HF\/.+)$/
|
||||
before_install: bash _ci/init.sh
|
||||
before_script: travis_wait bash _ci/cache_artifacts.sh
|
||||
script: travis_wait 30 bash _ci/release.sh
|
||||
|
||||
@ -4,36 +4,29 @@ The `.travis.yml` config file can be found in the root of the repository.
|
||||
|
||||
|
||||
## Stages and Jobs
|
||||
1. **Build**: Java Build with Unit and Integration Tests, WhiteSource
|
||||
2. **Release**: Publish to Quay & DockerHub, Publish the S3 staging
|
||||
3. **Company Release**: Publish to S3 release
|
||||
1. **Build**: Java build with unit tests, integration tests and WhiteSource scan.
|
||||
2. **Release**: Release with artifact deployment to Nexus and AWS Staging bucket.
|
||||
3. **Company Release**: Artifact deployment to AWS Release bucket.
|
||||
|
||||
|
||||
## Branches
|
||||
Travis CI builds differ by branch:
|
||||
* `master`:
|
||||
- regular builds which include only the _Build_ stage;
|
||||
- the _Build_ stage updates the `latest` T-Engines images (only
|
||||
from the `master` branch) on both Quay and DockerHub:
|
||||
- alfresco/alfresco-pdf-renderer
|
||||
- alfresco/alfresco-imagemagick
|
||||
- alfresco/alfresco-tika
|
||||
- alfresco/alfresco-libreoffice
|
||||
|
||||
* `ATS-*` (any branch starting with "ATS-"), `SP/1.3.N` and `SP/2.0.N`:
|
||||
- regular builds which include only the _Build_ stage;
|
||||
- although built and used on the CI agent, no docker images are updated on remote repositories;
|
||||
* `release`:
|
||||
- builds that include the _Build_ and _Release_ stages;
|
||||
- PR builds with release as the target branch only execute dry runs of the actual release,
|
||||
without actually publishing anything;
|
||||
* `release/SP/1.3.N` and `release/SP/2.0.N`:
|
||||
- builds that include the _Build_ and _Release_ stages;
|
||||
- PR builds with one of the release branches as the target branch only execute dry runs of the actual release,
|
||||
without actually publishing anything;
|
||||
- the branches should be deleted once the builds are completed
|
||||
* `company_release`:
|
||||
- builds that include only the `company_release` stage;
|
||||
* `master` / `SP/*` / `HF/*` branches:
|
||||
- regular builds which include the _Build_ stage;
|
||||
> On the `master` branch only the _Build_ stage updates the `latest` T-Engines images on
|
||||
> both Quay and DockerHub:
|
||||
> - alfresco/alfresco-pdf-renderer
|
||||
> - alfresco/alfresco-imagemagick
|
||||
> - alfresco/alfresco-tika
|
||||
> - alfresco/alfresco-libreoffice
|
||||
- if the commit message contains the `[trigger release]` tag, the builds will also
|
||||
include the _Release_ stage;
|
||||
- PR builds where the latest commit contains the `[trigger release]` tag will execute dry runs
|
||||
of the release jobs (no artifacts will be published until the PR is actually merged).
|
||||
* `ATS-*` branches:
|
||||
- regular builds which include only the _Build_ and _Tests_ stages;
|
||||
* `company_release` branch:
|
||||
- builds that include the _Company Release_ stage only.
|
||||
- the `company_release` branch should be used for one-off events; once used (a build
|
||||
completes), the branch should be deleted.
|
||||
|
||||
@ -42,65 +35,43 @@ All other branches are ignored.
|
||||
|
||||
## Release process steps & info
|
||||
Prerequisites:
|
||||
- the `master` branch has a green build and it contains all the changes that should be included in
|
||||
the next release
|
||||
- the `master` / `SP/*` / `HF/*` branch is green and it contains all the changes that should be
|
||||
included in the next release.
|
||||
|
||||
Steps:
|
||||
1. Create a new branch from the `master` branch with the name `ATS-###_release_version`;
|
||||
2. (Optional) Update the project version if the current POM version is not the next desired
|
||||
release; use a maven command, i.e. `mvn versions:set -DnewVersion=2.0.19-SNAPSHOT versions:commit`;
|
||||
3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes) through a new commit on the
|
||||
`ATS-###_release_version` branch;
|
||||
4. Open a new Pull Request from the `ATS-###_release_version` branch into the `release` branch and
|
||||
wait for a green build; the **Release** stage on the PR build will only execute a _Dry_Run_ of
|
||||
the release;
|
||||
5. Once it is approved, merge the PR through the **Create a merge commit** option (as opposed to
|
||||
_Squash and merge_ or _Rebase and merge_), delete the `ATS-###_release_version` branch, and wait
|
||||
for a green build on the `release` branch;
|
||||
6. Merge back the `release` branch into the `master` branch;
|
||||
7. Update the project dependencies (append the `-SNAPSHOT` suffixes)
|
||||
1. Create a new branch with the name `ATS-###_release_version` from the `master` / `SP/*`/ `HF/*`
|
||||
branch.
|
||||
2. Update the project version if the current POM version is not the next desired release; use a
|
||||
maven command, i.e.
|
||||
```bash
|
||||
mvn versions:set -DnewVersion=#.##.#-SNAPSHOT versions:commit
|
||||
```
|
||||
3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes - only for dependencies, not
|
||||
for the local project version).
|
||||
4. Create a new commit with the `[trigger release]` tag in its message. If no local changes have
|
||||
been generated by steps (2) and (3), then an empty commit should be created - e.g.
|
||||
```bash
|
||||
git commit --allow-empty -m "ATS-###: Release AIS #.##.# [trigger release]"
|
||||
```
|
||||
|
||||
> The location of the `[trigger release]` tag in the commit message is irrelevant.
|
||||
|
||||
Steps (6) and (7) can be done either directly from an IDE or through the GitHub flow, by creating
|
||||
another branch and PR. Just make sure you don't add extra commits directly to the release branch,
|
||||
as this will trigger another release.
|
||||
|
||||
After the release, the reference deployments (docker-compose, helm) should be updated with the
|
||||
latest docker image tags.
|
||||
|
||||
### Release of a Service Pack (SP/1.3.N or SP/2.0.N)
|
||||
Prerequisites:
|
||||
- the `SP/<version>` (<version> could be 1.3.N or 2.0.N) branch has a green build and it contains all the changes that should be included in
|
||||
the next release
|
||||
|
||||
**NOTE**: Make sure you release the proper version and the `SP/<version>` is merged into the correct `release/SP/<version>` (both having the same version).
|
||||
E.g. When releasing a 1.3.N Service Pack, a new branch (`ATS-###_release_version`) should be created from `SP/1.3.N` and the PR should target the `release/SP/1.3.N` branch.
|
||||
|
||||
Steps (similar to those describing the release from `master`):
|
||||
1. Create a new branch from the `SP/<version>` (SP/1.3.N or SP/2.0.N) branch with the name `ATS-###_release_version`;
|
||||
2. (Optional) Update the project version if the current POM version is not the next desired
|
||||
release; use a maven command, i.e. `mvn versions:set -DnewVersion=1.3.1-SNAPSHOT versions:commit`;
|
||||
3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes) through a new commit on the
|
||||
`ATS-###_release_version` branch;
|
||||
4. Open a new Pull Request from the `ATS-###_release_version` branch into the `release/SP/<version>` branch and
|
||||
wait for a green build; the **Release** stage on the PR build will only execute a _Dry_Run_ of
|
||||
the release;
|
||||
5. Once it is approved, merge the PR through the **Create a merge commit** option (as opposed to
|
||||
_Squash and merge_ or _Rebase and merge_), delete the `ATS-###_release_version` branch, and wait
|
||||
for a green build on the `release` branch;
|
||||
6. Merge back the `release/SP/<version>` branch into the `SP/<version>` branch;
|
||||
7. Update the project dependencies (append the `-SNAPSHOT` suffixes)
|
||||
> If for any reason your PR contains multiple commits, the commit with the `[trigger release]`
|
||||
tag should be the last (newest) one. This will trigger the Release dry runs.
|
||||
5. Open a new Pull Request from the `ATS-###_release_version` branch into the original
|
||||
`master` / `SP/*` / `HF/*` branch and wait for a green build; the **Release** stage on the PR build
|
||||
will only execute a _Dry_Run_ of the release.
|
||||
6. Once it is approved, merge the PR, preferably through the **Rebase and merge** option. If the
|
||||
**Create a merge commit** (_Merge pull request_) or **Squash and merge** options are used, you
|
||||
need to ensure that the _commit message_ contains the `[trigger release]` tag (sub-string).
|
||||
|
||||
## Company Release process steps & info
|
||||
Prerequisites:
|
||||
- Engineering Release of the desired version has been done.
|
||||
|
||||
Steps:
|
||||
1. Create a new `company_release` branch from `release`. This job uses the git tag to identify the
|
||||
version to be uploaded to S3 release bucket.
|
||||
2. If the last commit on `company_release` branch contains `[skip_ci]` in its message it will
|
||||
prevent Travis from starting a build. Push an empty commit in order to trigger the build,
|
||||
`git commit --allow-empty -m "Company Release <version>"`. Wait for a green build on the branch.
|
||||
3. Delete local and remote `company_release` branch.
|
||||
- The **Release** stage is complete - i.e. the release commit is tagged and the release
|
||||
artifacts are deployed on Nexus.
|
||||
|
||||
### Release of a Service Pack (SP/1.3.N or SP/2.0.N)
|
||||
Follow the steps described in the previous section, but instead of creating the `company_release` from `release`, it needs to be created from the proper `release/SP/<version>` (depending on what version needs the Company Release).
|
||||
Steps:
|
||||
1. Create a new `company_release` branch from the `master` / `SP/*`/ `HF/*` branch. This job uses
|
||||
the latest branch git tag to identify the version that must be uploaded to the S3 release bucket.
|
||||
2. Wait for a green build on the branch.
|
||||
3. Delete local and remote `company_release` branch.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user