Creating Tagged Releases¶
This tutorial covers creating Tagged Releases with Github, Travis and Mission Control.
The ability to create tagged releases in our molo sites, allows us to test a QA version of our code, without merging our changes into the develop branch. Note that this currently only works for sites like TuneMe and Springster, not molo.core or a particular package.
This tutorial will explain how to create a tagged release for a branch on TuneMe, as an example.
Creating your first tagged release¶
Ensure everything is configured¶
Make sure that Travis is set up for to create tagged releases. See this commit as an example of how to do this. Check that the account is set up to handle tagged releases on Docker Hub. At the time of writing this, both Springster and TuneMe are set up to handle tagged releases.
Create the tag¶
Create the tag locally, on the branch that you want to test in a QA environment.
The tag name should be something short and descriptive.
git tag <tag name>
Tell github about the tag by pushing your tag
git push origin <tag name>
You can check that that tag has been created by going to the
/releases section on Github.
https://github.com/praekelt/molo-tuneme/releases or more specifically for the tags,
Check on the Docker Image creation process¶
If you check Travis, it should automatically start a new build, named after your tagged release.
Once all of the tests have passed on Travis, it will bundle everything up and create a Docker Image, containing everything needed to run an instance of your code in QA.
That image will be tagged with the same tag you used earlier.
If everything passes, the Image will then be pushed to the associated account on Docker Hub.
In this example, it will be
You should see the tag you created, listed at the top.
Update QA Mission Control¶
Once you see the tag, Go to QA Mission Control, find the QA instance that you want to test with.
Click on the ‘edit’ link.
Check the field called
Change the listed docker image being used to your tag. In this case it will be
Finally, hit ‘Submit’ at the bottom of the page to ensure the changes are made. The site will restart and you should see your changes when it gets back up and running.
One of the possible gotchas with QA instances is the possiblility of corrupting the DB with migrations. Speak to someone if you’re not sure what affects your changes could have.
Recreating a tagged release¶
Okay, so you’ve made some changes and you want to see those new changes in QA.
Follow the same process as above¶
You then need to recreate the tags, push them to Github, wait for tests to pass and Docker Hub to update. You don’t need to update the Docker Image on Mission Control. Instead, just hit the restart button for the QA instance on MC.
Congrats! We can now test our code in a QA environment before commiting our code to the develop branch. Note that if your work is being done on a package, it needs to have a release created before you can test on a QA site.