As a marketer for our family of developer tools, I get the chance to talk with developers doing really cool things with code they host on Bitbucket. Recently I had the chance to meet the team over at CloudCannon and discuss how they develop their application.
Similar to other small teams, they've faced challenges with setting up a solid continuous delivery model and ensuring the code released is of the highest quality possible. But thanks to the bitHound Bitbucket add-on and their own custom Bitbucket extension, they were able to create a workflow that’s a perfect fit. Here’s how it works – hopefully this will inspire a few ideas for your team’s process.
CloudCannon’s need for speed
CloudCannon makes it possible for non-tech savvy users to update their own websites. Developers build a static or Jekyll site with full control over design, libraries, and frameworks used. Then non-developers log in and update the content inline, with no prior knowledge of development needed.
Like all SaaS companies, they live and die based on their ability to release fixes and features to their customers as frequently as possible. Git’s support for branch-and-merge workflows, plus Bitbucket’s extensibility, plus Docker’s flexibility is their recipe for dev speed (with a dash of automation thrown in).
Node.js, microservices, and bitHound (oh my!)
Their infrastructure, written in Node.js, is entirely composed of microservices. Each repository contains a stable master (trunk) branch, a production branch, and feature branches as needed.
For each new feature, they create feature branches within every microservice repository it touches. To keep track of changes on their feature branches, they implemented a strict commit message convention. Each commit has to indicate the type of change made with “fix, feature, or chore”. For example:
fix(broken sharing ui)
feature(added ssl interface)
chore(fixed mixed whitespace)
These conventions come in handy when it comes time to tell customers about each release. They group commits together based on keyword to create detailed release notes they can publish in their documentation.
Once feature development is complete, they merge those changes back into the stable master branch. At this point in their workflow, CloudCannon needed a way to enforce additional quality checks. After meeting the bitHound team at Atlassian’s very own AtlasCamp event last year, they discovered that bitHound could do just that.
If you’re unfamiliar with bitHound, it’s a continuous code analysis tool for JavaScript that identifies risks and priorities inside the project's code and dependencies. Using bitHound’s add-on for Bitbucket, CloudCannon could flag and update any packages or JS warnings before they made it into a release. bitHound statistics display right inside the Bitbucket UI on every repository CloudCannon creates.
Using Docker containers for deployments
Once features have passed the package quality check, changes are deployed to their staging environment. How does this happen? I’m glad you asked – this is where things get really interesting.
When CloudCannon set out to build their continuous integration and delivery pipeline, they found it difficult to find a solution that fit their exact requirements. What do you do when you’re an engineer and in need of a tool? You build your own! So CloudCannon did just that, creating their very own continuous integration and delivery tool called Weldr.
Named for its ability to ‘weld’ together Docker containers, Weldr is a node.js application that uses Express.js to create web services for the team to interact with. CloudCannon automatically kicks off builds using Bitbucket’s webhooks with each push to their master branch.
Tying together several bash scripts, Weldr then pulls the latest repository change from Bitbucket, spins up a new Docker image, starts up all necessary services, and finally publishes a log file of how the build went. If all is well in the log file, the developer then runs through a series of scripted manual tests to ensure everything is working as expected.
Currently the team needs to open Weldr to view the results, but they plan to enhance the process by sending build status updates to Bitbucket’s Build Status API. This will show them the status of builds without having to leave the Bitbucket repository.
When a batch of new features and fixes are ready for release, they repeat the process to deploy to production (which happens 2-3 times a week), with one minor change. Instead of automatically triggering production deployments, they decided to make it push-button to avoid any accidental mistakes.
…and so can you
Using Bitbucket’s extensibility, bitHound’s quality control, and their own custom continuous integration CloudCannon is able to deploy to their end-users with zero downtime – a feat they’re rather proud of.
If you’d like to implement pieces of CloudCannon’s process, you can find the bitHound add-on for Bitbucket here. And although Weldr is unique to CloudCannon, you can use just about any continuous integration tool to mimic their process. Many of which, like Bamboo, Wercker, and AWS CodeDeploy, integrate directly with Bitbucket for automatic deployments and build status.
Automation is just the beginning. For more on Git workflows and using Bitbucket for continuous delivery, head over to The Pipeline our continuous delivery hub.
