Since we’ve covered most of the meat in the previous two blog posts with CocoaPods, Cedar and Rake, we will now finish it up setting up our own continuous integration server using Travis-CI.
A continuous integration server (also known as a CI box) is a server that is runs “somewhere” (could be locally on your own network, or off in the cloud) that continuously runs automated tests or builds when a baseline is changed. In other words, every time a change is done on a project, the server makes sure that the code builds and unit/integration tests pass ensuring that the quality of the software. When a change breaks things, the continuous integration server will let use know immediately via email notifications and badges, but can be as grand as alarms and monitor alerts throughout an entire building.
Setting up servers to continuously run these automated checks can be extensive. If you plan on setting up a box locally on your own network, I recommend Jenkins. It is quite the package and provides various customizable options. There are many other solutions out there as well, but for the scope of this blog post we will be using a hosted CI solution from a service provided by Travis-CI. While Travis-CI charges a hefty fee for private repositories ($129 per month, ouch), it has a free service for open source public repositories. With that said, in order to use this service, you need to have your code hosted on Github to get started. If you need help getting up and running (I don’t want this to interrupt our CI setup), check out this helpful guide after you’ve created a free Github account. You can also get additional help from the Github website (Bootcamp) as well. Since CuckooForCedar is already on the Github and will serve as the example for this post, let’s get started with CI!
To get started, we need to log into Travis-CI. When you go to their homepage, in the upper right hand corner you can login using your Github credentials. Once your logged in, if you click on your name and then select “Accounts,” you will be taken to a page that has all your public Github repositories. In order for Travis-CI to have the ability to pull down your repo and future commits, you will need to flip the switch from “Off” to “On.” If you are having trouble seeing all your public repos, click on the “Sync Now” button to have Travis do a fetch for them.
Once that is flipped, every time you push a commit from your local repo to Github, Travis-CI will attempt to build your project and run any scripts you listed in a configuration file that is present in root of the repo called “.travs.yml”.
Before we get started with the configuration file, we need to share our targets in Xcode for Travis-CI to work:
After sharing the schemes, we need to create a very small BASH script. Since our project has some dependencies (CocoaPods, Cedar, xcpretty), we need to make sure that these get installed on Travis before we attempt to run tests. Here is an example setup BASH script:
1 2 3 4 5
We will setup this script to be run on Travis before we run our tests, and it can also be used by others to setup their environment.
After creating an setup script, create the .travis.yml file using your favorite text editor (don’t forget to give this file the correct permissions, 755 or -rwxr-xr-x). Once it’s created, add the following:
1 2 3
The first line in the .travis.yml file tells Travis which platform to build and run against. Since this is an iOS project, we enter “objective-c”.
The second line tells Travis to run the setup.sh BASH script before we run our tests. Generally, all commands given in the “install” portion of the .travis.yml file are used to install any prerequisites or dependencies. The full lifecycle of Travis can be found here.
The third and final line, is what to run for builds and tests. All commands that are placed here must exit with code 0 on success, otherwise the build is considered a failure. Our Rakefile is properly setup to do this, so we just run rake (if you followed along in the previous post, the default rake task is to run the Specs).
Since Travis is already “listening” to the repo, to get Travis to build, we just commit our changes and push to Github. Once we do, we can go to our Travis page, and checkout the status of the build:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Now that we are all setup, we are good to go for future changes. If you are working with a team of developers, you will be notified immediately by email when something goes wrong. And speaking of being notified, Travis gives you a nice little badge that you can display on your project’s Github page.
If you look up at the top of the build page, you will see a badge that is green that says, “build passing.” If you click on it, Travis will give a pop up of all the links to the build status. Since we are going to put this on Github, let’s copy the “Markdown” text:
Now that we have the badge link, you can add it to the README.md file:
1 2 3 4
Now when you go to the Github page for the project, you will see a shiny green (or red if something goes wrong) badge.
It looks like our testing “Dev-Ops” track has come to a end. I wouldn’t say it fun, but wasn’t terrible either. It’s just one of those processes that might not seem all that valuable for such a small project here (or even yours particularly for that matter), any huge project that has continuous integration setup will save you tons of time and heartache in the future (and every huge project started out small), and is just a small price to pay to keep sanity levels from going overboard.
Since we have a fine testing framework and build process going forward, I will continue going full speed ahead with more advanced iOS testing techniques. So crack open your beers (or any other beverage of choice), as completing a setup like this is something to celebrate!