Integrating external CI services
You want to use continuous integration with automated testing? Deploy only if your tests succeed? This article gives you the big picture about how to do just that on fortrabbit.
"Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day." (Wikipedia)
Modern web application development cannot get around continuous integration. This basically means applying an incremental and iterative software development style: Code, test, deploy. Then: code, test, deploy. Then: .. and so on, you get the picture.
With fortrabbit alone, you can easily do the code and deploy part. To do the test bit, you have two choices:
- Run tests locally before each git push
- Integrate a a CI provider in your deployment and automate the whole process.
This article helps you to do the second and integrate a CI provider in your workflow.
Most, if not all, of the CI providers assume that you host your code on a public available version control (eg Git) repository. This does not mean your repository publicly accessible without authentication, just that it's not on your local host. Example for those public repositories are Github or Bitbucket and many more.
The workflow now is quite straight forward:
- Push to your repository (eg Bitbucket, Github, ..)
- Setup a hook, which notifies your CI provider whenever you push something (the CI providers will tell you how)
- Now the CI providers pulls the changeset and runs your tests
- If the tests succeed, the CI provider will deploy your App to fortrabbit
That's not hard at all. The general concepts of our multi stage environment article apply, just the local branch -> remote branch mappings are different.
For example, if you have three environments: testing, staging and production and if you use Bitbucket as your repository, you would create three local branches: test, stage and prod. All three local branches would map directly to branches of the same name on Bitbucket. On Bitbucket, you would now set up your deployment hook, which tells your CI provider (eg Codeship or Wercker or ..).
$ git clone firstname.lastname@example.org:your-username/your-repo-name.git $ cd your-repo-name # rename master branch to test branch, if you haven't already $ git branch -m master test # create stage and prod branch, if you haven't already $ git branch stage $ git branch prod # do some stuff in the test branch $ git checkout test # .. code $ git commit -am 'My changes' # on first push to your bitbucket remote, make sure use the "-u" switch $ git push -u origin test # merge test into stage $ git checkout stage $ git merge test $ git push -u origin stage # merge stage into prod $ git merge stage $ git checkout prod $ git push -u origin prod
Here is a complete schema of the above example:
All you have to do is setup the deploy hook on your CI provider. This differs from provider to provider.