Creating Release

In Jira, go to the Releases Page and add a new release name with start date and description.
Move any issues that have been resolved, or that are planned to be resolved, to this release. The easiest way to do this is to filter down to the results you want and bulk edit them to change the 'Fix Version/s' field to match the release name. Try this filter - Done in current sprint, no fixversion
Create a new page using the JIRA Report Blueprint by clicking the white elipsis in the page header. Go to "New release" and fill out the details for this release. The JIRA report on that page defaults to beta-002 so that needs to change.
Add the link to Slack's #general channel and mention @channel so all users are notified, e.g.
```
@channel new release https://hee-tis.atlassian.net/wiki/display/TISDEV/beta-001
```

Prep a release dev side

title Release Process

Developer->Github: Push to master
Github->Jenkins: Webhook
Jenkins->Jenkins: Build docker image with version
Jenkins->Github: Tag with version
Jenkins->Docker Registry: Push versioned image
Jenkins->Docker Registry: Push latest image
Jenkins->Ansible: Deploy latest image
note left of Ansible: latest deployed to dev
Ansible->Platform: Copy docker-compose templates
Ansible->Platform: Run docker-compose
Jenkins->CI Tests: Run tests

Maven Projects

The project should already have the maven-release-plugin present, if it does not, here is how to add it:

In the pom.xml add in the plugin along with the proper scm link (make sure that the scm link matches the project's github repo). The example below is from revalidation:

<scm>
 <developerConnection>scm:git:git@github.com:Health-Education-England/TIS-REVALIDATION.git</developerConnection>
 <tag>HEAD</tag>
</scm>

...

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-release-plugin</artifactId>
 <version>2.5.2</version>
 <dependencies>
 <dependency>
 <groupId>org.apache.maven.scm</groupId>
 <artifactId>maven-scm-provider-gitexe</artifactId>
 <version>1.9.4</version>
 </dependency>
 </dependencies>
</plugin>

You should start with common projects that are required for others to compile (such as TIS-SHARED-MODULES).

Check that your current project version in the POM is a "snapshot" version, the release prep will fail if it is not.

Check that your public ssh key is uploaded to your github account, the release prep needs to talk to github and will use your account. If it is not add it, instructions here:

https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/

If all the above are OK then Run:

mvn release:prepare

You will be prompted to name the realease version, the release tag, and the new dev version. As an example, for the beta-001 release these are:

release version name: beta-001

release tag: beta-001

new development version: beta-002-snapshot

If it all went well you should notice two new commits in your local git repo. The first one is the release (it has the tag you specified), the second one is the new development snapshot.

Finally for a:

git push

The release is now on github.

If something went wrong you can do the following:

mvn release:rollback
git tag -d beta-001
git push origin :refs/tags/beta-001

The above rolls back your attempt to release and deletes the tag you set (ofcourse change the code to the tag you need).

UI Projects (npm and bower)

At the time of writing only TIS-COMMON is UI only.

First update the version in bower.js and package.js then push with a tag like so:

git commit -am "Release beta-001"
git tag -a beta-001 -m "Release version beta-001"
git push origin master --tags

Then change the versions to "beta-002-snapshot" and push again.

Validating Docker Versions

The build pipeline now tags the Docker images so both images and containers can be inspected to validate their build settings. The Common image is the only exception to this but this will be brought in line with the rest of the builds.

To inspect the concerns image, for example, run the following on the dev server;

$ export SERVICE=concerns
$ docker inspect -f '{{ index .Config.Labels "com.transformuk.hee.tis.build_version" }}' docker-hee.transformcloud.net:5000/hee/${SERVICE}:latest

To inspect the build version of a container is a bit eaiser;

$ docker inspect -f '{{ index .Config.Labels "com.transformuk.hee.tis.build_version" }}' concerns_concerns_1

It is a useful sanity check to make sure that the latest tag on dev is the version you expect.

Once you have established the versions of the images, they can be added to the stage/platform.yml or prod/platform.yml if they are ready to release.

Proposed Build Pipeline

This pipeline is slightly different to the version above, in this version we build master to dev, r

title Release Process

Developer->Github: Push to master
Github->Jenkins: Webhook
Jenkins->Jenkins: Build docker image with version
Jenkins->Docker Registry: Push versioned image
Jenkins->Docker Registry: Push latest image
Jenkins->Ansible: Deploy image to dev
note left of Ansible: latest deployed to dev
Ansible->Platform: Copy docker-compose templates
Ansible->Platform: Run docker-compose
Jenkins->Platform: Run CI Tests
Jenkins->Github: Tag as release candidate

Previous Releases