The process of packaging and validating your releases can get time consuming, especially when you have multiple projects on the go.
For consistency (as well as security), it is good practise to try to automate this process.
Setting up continuous integration (CI) can take a while to configure and get right, in most cases it requires a lot of change. But done right, it can streamline your processes and help your team stay focused on building software vs deploying code.
Here’s a summary of the tools we used to implement our CI workflow. To note you can implement this in small steps; building, packaging, then deploying.
Step 1. Source control.
For CI, your source control needs to be accessible via a range of tools (as well as any dependancies). If you have remote developers you probably want to consider this in the cloud.
We previously used a local on-premise SVN repository which was fine, but it didn’t easily integrate with the tools we had selected, nor did it support pull requests and visualisation tools etc, so we initiated a proof of concept (POC) from SVN to GIT (via BitBucket), this worked well for 1 project, so we took the plunge, migrated the rest, and put SVN in readonly mode.
We decided to use BitBucket as we were invested in the Jira ecosystem (It gave visibility of commits in Jira), it supports pull requests, and 2FA, and was cheaper than GitHub (at the time!).
There are other advantages too, which I’ll go into later.
Step 2. Agree on a branching strategy.
Originally we had a feature branch strategy, where we branched off master, and worked on a branch (which would contain all the tasks for a feature), but we often got times where a customer would be selective about the items they were happy to release which resulted in merging out the task and often caused regressions. So we looked at alternative branching strategies We have multiple developers working on various features, and sometimes requirements which change or require the occasional hot fix.
We chose Git Flow as it matched our workflow.
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow
Its not an easy thing to change, so your team need to understand, support and ensure that branches are made and merged correctly (using the correct convention!)
BitBucket additionally supports pull requests, so we can ensure that the team leaders can review the commits before they are merged.
The branches are important as this will be used by the automation tools to know what environment to release to.
Step 3. Start automating
Once you’re happy that all your developers are committing correctly then its time to take the plunge into continuous deployments (one step at a time)
Step 3.a Choose an automation server.
In order to automate you need an automation server, this is going to co-ordinate the events and be responsible for the continuous delivery.
We selected Jenkins as its a well established tool, its open source too.
Step 3.b. Linking your CI server to your source code.
This is where your choice of source control matters, most source control are unable to trigger events, but as it happens BitBucket supports webhooks.
If you engage web hooks, then each time you commit code to your branch it will fire a build of your code. If you don’t have web hooks then someone needs to tell the server to trigger.
Step 3.c. Broadcast the event.
You’ll want to tell your team whether it passed or failed, you can do this with a build monitor screen, but if you’re like us, you may use hipchat, you can add a plug in to Jenkins, to broadcast the build to your team.
As a manager, its nice to see these without needing to ask.
Step 3.d. Deploy to your server(s)
We use AWS Code deploy, Jenkins packages the artifact via a plug in (AWS Code deploy). Which packages the artefacts into an S3 bucket and then fires Amazon code deploy to each EC2 instance.
We use SNS to confirm this was successful (or not).