alfresco-transform-core/docs/build-and-release.md

Build

The alfresco-transform-core project uses Travis CI.
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

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;
  • the company_release branch should be used for one-off events; once used (a build completes), the branch should be deleted.

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

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)

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

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.

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