Once a developer has some code ready, it should be tested, reviewed, merged and deployed to staging and production servers. The build pipeline is a composition of all these steps, a chain of actions and states. I would like to explain how the Australian setup works and open that for discussions.
The short summary of events
- push code to Github
- Travis tests code
- Buildkite is notified if the Travis tests passed
- one click deploys to our staging server
- another click merges into master and deploys to production
The more detailed version
Whenever we push code to the openfoodnetwork repository, Github sends out notifications to several services. Travis is notified and runs all the automated tests. Once Travis finishes testing, it tells Github if the code passed or failed. If it passed, Travis also triggers a deploy event.
Buildkite listens to deploy events. So whenever some code passes the tests in Travis, we trigger a build in Buildkite. Buildkite doesn’t really do anything just yet. The build just sits there and waits for someone to click “Stage it!”. It then deploys that code to our staging server.
If we are happy with the results on the staging server, we hit another button and the code is merged into the master branch and deployed to the Australian production server.
A slightly different path
If somebody opens a pull request on Github, Travis tests that code as well. Additionally, Codeclimate checks the code style. If the branch in question is within the main repository, it can go through Buildkite as described above. If it is in another repository, a developer has to import that branch into the main repository in order to trigger Buildkite and deploy it.