...

How to do a release:

• While in the TIS-DEVOPS folder, do a pull to make sure your local is up to date (i.e. git pull) then create a new branch via the terminal (i.e. git checkout -b NewBranchName)

• Compare the versions of every microservice/etl in TIS-DEVOPS/ansible/vars/stage/platform.yml  with the versions of their corresponding pom.xml or package.json files in the GItHub repository https://github.com/Health-Education-England. Update the platform.yml file accordingly to ensure that it is up to date with the GitHub repository and make a note of all the updated microservices/etls.

          Remember the following:

          For repositories that have services within them (i.e. TIS-PROFILE, TIS-TCS e.t.c),  the pom version required for release is the one in the service folder (i.e. TIS-TCS/tcs-service)

          For TIS-ADMINS-UI, there is no pom.xml file as it is a front end piece. However there is a package.json file which would have a version number. Use that version number for the release.

• Finalise the artefacts you want to deploy using jenkins

          Navigate to  https://build.tis.nhs.uk/jenkins/ 

          For all updated microservice/etl, build using the 'Final Tag' as a parameter,    

• Create a main.yml file for the release in TIS-DEVOPS/ansible/releases/TIS-XX/main.yml  (where XX is the release number)
• import the .yml files for all the updated microservice/etl. (Hint: use previous releases as a guide if in doubt)
• Commit your changes and push (i.e. git add -A >> git commit -m "TIS-XX deployed to Stage" >> git push -u origin NewBranchName)
• Create a PR to get your changes approved and merged
• Once merged, check to https://build.tis.nhs.uk/jenkins/job/devops/  verify that it has run.
• Release to stage → https://build.tis.nhs.uk/jenkins/job/release-stage-pipeline/ - Click on 'Build with Parameters' and in the 'RELEASE_NUMBER' section, type in TIS-XX where XX is the release number
• Ask everyone to check their stuff in stage once the job finishes by skipping to the 'Release Documentation' section
• Once Stage is verified by the productowners and they give a Prod release the go-ahead, move to next steps
• Update your TIS-DEVOPS master branch and create a new branch
• Modify TIS-DEVOPS/ansible/vars/prod/platform.yml with all the changes done in TIS-DEVOPS/ansible/vars/stage/platform.yml
• Commit your changes and push (i.e. git add -A >> git commit -m "TIS-XX deployed to Prod" >> git push -u origin NewBranchName)
• Create a PR to get your changes approved and merged
• Once merged, check to https://build.tis.nhs.uk/jenkins/job/devops/  verify that it has run.
• Release to prod → https://build.tis.nhs.uk/jenkins/job/release-prod-pipeline/   - Click on 'Build with Parameters' and in the 'RELEASE_NUMBER' section, type in TIS-XX where XX is the release number
• Notify the slack channel

Release Documentation

• Create the release documentation like below → Jira query to add tasks: status in ("Ready for release") AND status changed to ("Ready for release") after 2016-12-07 before now() AND fixVersion is EMPTY ORDER BY assignee ASC, status DESC, updated ASC

          Click on Search >> Search all issues >> Enter Query     OR    Search >> View all issues >> Advanced >> Enter Query

1. In Jira, go to the Releases Page and add a new release name with start date and description.
2. 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
3. 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.

4. Add the link to Slack's #general channel and mention @channel mention @channel so all users are notified, e.g. 

   Code Block
   @channel new release https://hee-tis.atlassian.net/wiki/display/TISDEV/beta-001

Prep a release dev side

Image Removed

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:

...

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

Image Removed

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

childrenPrevious Releases