ATS-628: Update release process

.travis.yml

@@ -19,8 +19,7 @@ branches:
   only:
     - master
     - /^SP\/.+$/
-    - release
+    - /^HF\/.+$/
-    - /^release\/SP\/.+$/
     - 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

docs/build-and-release.md

@@ -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
+1. **Build**: Java build with unit tests, integration tests and WhiteSource scan.
-2. **Release**: Publish to Quay & DockerHub, Publish the S3 staging
+2. **Release**: Release with artifact deployment to Nexus and AWS Staging bucket.
-3. **Company Release**: Publish to S3 release
+3. **Company Release**: Artifact deployment to AWS Release bucket.
 
 
 ## Branches
 Travis CI builds differ by branch:
-* `master`:
+* `master` / `SP/*` / `HF/*` branches:
-  - regular builds which include only the _Build_ stage;
+  - regular builds which include the _Build_ stage;
-  - the _Build_ stage updates the `latest` T-Engines images (only 
+    > On the `master` branch only the _Build_ stage updates the `latest` T-Engines images on 
-  from the `master` branch) on both Quay and DockerHub:
+    > both Quay and DockerHub:
-    - alfresco/alfresco-pdf-renderer
+    > - alfresco/alfresco-pdf-renderer
-    - alfresco/alfresco-imagemagick
+    > - alfresco/alfresco-imagemagick
-    - alfresco/alfresco-tika
+    > - alfresco/alfresco-tika
-    - alfresco/alfresco-libreoffice
+    > - alfresco/alfresco-libreoffice
-  
+  - if the commit message contains the `[trigger release]` tag, the builds will also 
-* `ATS-*` (any branch starting with "ATS-"), `SP/1.3.N` and `SP/2.0.N`:
+  include the _Release_ stage;
-  - regular builds which include only the _Build_ stage;
+  - PR builds where the latest commit contains the `[trigger release]` tag will execute dry runs 
-  - although built and used on the CI agent, no docker images are updated on remote repositories;
+  of the release jobs (no artifacts will be published until the PR is actually merged).
-* `release`:
+* `ATS-*` branches:
-  - builds that include the _Build_ and _Release_ stages;
+  - regular builds which include only the _Build_ and _Tests_ stages;
-  - PR builds with release as the target branch only execute dry runs of the actual release, 
+* `company_release` branch:
-  without actually publishing anything;
+  - builds that include the _Company Release_ stage only.
-* `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;
   - 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 `master` / `SP/*` / `HF/*` branch is green and it contains all the changes that should be 
-  the next release
+ included in the next release.
 
 Steps:
-1. Create a new branch from the `master` branch with the name `ATS-###_release_version`;
+1. Create a new branch with the name `ATS-###_release_version` from the `master` / `SP/*`/ `HF/*` 
-2. (Optional) Update the project version if the current POM version is not the next desired
+branch.
- release; use a maven command, i.e. `mvn versions:set -DnewVersion=2.0.19-SNAPSHOT versions:commit`;
+2. Update the project version if the current POM version is not the next desired release; use a
-3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes) through a new commit on the
+maven command, i.e.
- `ATS-###_release_version` branch;
+    ```bash
-4. Open a new Pull Request from the `ATS-###_release_version` branch into the `release` branch and
+    mvn versions:set -DnewVersion=#.##.#-SNAPSHOT versions:commit
- wait for a green build; the **Release** stage on the PR build will only execute a _Dry_Run_ of
+    ```
-  the release;
+3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes - only for dependencies, not
-5. Once it is approved, merge the PR through the **Create a merge commit** option (as opposed to
+ for the local project version).
- _Squash and merge_ or _Rebase and merge_), delete the `ATS-###_release_version` branch, and wait 
+4. Create a new commit with the `[trigger release]` tag in its message. If no local changes have 
- for a green build on the `release` branch;
+been generated by steps (2) and (3), then an empty commit should be created - e.g.
-6. Merge back the `release` branch into the `master` branch;
+     ```bash
-7. Update the project dependencies (append the `-SNAPSHOT` suffixes)
+     git commit --allow-empty -m "ATS-###: Release AIS #.##.# [trigger release]"
+     ```
  
-Steps (6) and (7) can be done either directly from an IDE or through the GitHub flow, by creating
+     > The location of the `[trigger release]` tag in the commit message is irrelevant.
-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 
+     > If for any reason your PR contains multiple commits, the commit with the `[trigger release]`
-latest docker image tags.
+     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
-### Release of a Service Pack (SP/1.3.N or SP/2.0.N)
+`master` / `SP/*` / `HF/*` branch and wait for a green build; the **Release** stage on the PR build
-Prerequisites:
+ will only execute a _Dry_Run_ of the release.
- - 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
+6. Once it is approved, merge the PR, preferably through the **Rebase and merge** option. If the 
-  the next release
+**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).
-**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)
 
 ## Company Release process steps & info
 Prerequisites:
- - Engineering Release of the desired version has been done.
+  - The **Release** stage is complete - i.e. the release commit is tagged and the release 
+  artifacts are deployed on Nexus.
 
 Steps:
-1. Create a new `company_release` branch from `release`. This job uses the git tag to identify the
+1. Create a new `company_release` branch from the `master` / `SP/*`/ `HF/*` branch. This job uses 
- version to be uploaded to S3 release bucket.
+the latest branch git tag to identify the version that must be uploaded to the S3 release bucket.
-2. If the last commit on `company_release` branch contains `[skip_ci]` in its message it will
+2. Wait for a green build on the branch.
- 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.
-
-### 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).