Creating a Marvel iOS App from scratch.. Part 3 | Travis, Danger and Fastlane ..

This is the third part of a series of posts covering how to create an iOS app from scratch, using many different pods and tools that will make your life easier. If you missed the previous parts, check them out, first and second part. In this post i’m going to talk about continuous integration, Danger and Fastlane.

The source code for this project is available at this repository. I’ve created a tag for this post called v0.3, you just need to clone the repo and switch to tag v0.3.

Continuous Integration

Continuous Integration(CI) is an extensive subject, with several tutorials and books written about it, and yet is a relative simple concept.

Integrate your code as often as possible to find out bugs early on, before hiting production.

As defined in ThoughtsWorks site.

"Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily. "

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” Martin Fowler

Bellow, you can find more information about the subject.

Continuous Integration | ThoughtWorks

Basically, we must have something that will keep an eye on our repository and run an automated build | test | deploy process every time anything changes. That something is a CI server. They come in all shapes and sizes, you can find a list of them here. This blog post will make use of Travis, a CI that plays really well with github and is the main choice for open source projects hosted on Github.

Travis

To use travis we need first to create a file called .travis.yml

You can notice that our build is using a variable called $MARVEL_API_PRIVATE. We need to define it because we are using cocoapods-keys. Cocoapods-keys gem will need this information, during build time. Someone could simply place the value inside .travis.yml, but lets try to make a little more difficult to steal that using encryption.

We can encrypt a variable using travis ruby gem. But first let's install it:

gem install travis

Login in using travis gem:

travis login

Encrypt:

travis encrypt MARVEL_API_PRIVATE={YOUR_KEY} --add

We can use this approach for any other variable that we need during build.

Creating Account on travis and opt in repo ..

After that, we still need to create an account on travis and opt in our repo to use CI.

This is all there is, after that you can check your builds everytime a new push or PR is added to your Repository.

Travis is very customizable as you might expect, you can find many different configurations, they have extensive documentation about this subject. I recommend starting with a simple one and build upon that.

Also worth mention, you can see that in the script phase of our travis we only call two things.

script:
- fastlane test
- bundle exec danger

The first one:

- fastlane test 

Is our automated pipeline, the one we created in the previous blog post. For our example we are only running tests and generating coverage, but there is much more we can do. Fastlane can handle and automate your entire pipeline, test, build, deploy, generate and upload screenshots, send notifications and more. There are many tutorials on the internet covering all those topics, you should definitelly check them. The important thing here is once we have master it on our developer machine, running it inside the CI is really easy. All we need is to call the Fastlane's lane (e.g.: our "test" for instance) and we are good to go.

Keep in mind: first make sure you have your automated pipeline working locally, them bring the CI , these can save you hours.

The second one:

- bundle exec danger

Is all about code review … Let's dive into it .

Danger Systems ..

Danger is an amazing new tool created by orta, Felix Krause and other great developers.

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review. You can use Danger to codify your teams norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.
— Danger Systems

You can find an initial "Getting Started" guide and many different DangerFile examples on the site. The documentation cover pretty much everything needed, i will mention a few points that i think deserve a remider.

Also needed

• Create a bot user on github. You need to create another user, to use as a bot
• Create a token for the Bot user, allowing it to comment on our repo. Create the token here. For open source projects the bot should have only public_repo permission.
• Register the token on travis, this is not quite well documented.

You need to add an environment variable named DANGER_GITHUB_API_TOKEN containing the value of your Bot's Token, also dont forget to opt int "Display value in build log" before hiting Add.

Dangerfile

I'm using for this project a version with the slather danger plugin. This plugin allows danger to use slather information inside the PR comment. A great enhancement for Danger, developed by Bruno Mazzo, a very talented developer that works with me at Concrete Solutions.

You can see mine Dangerfile bellow:

This will allow our bot to comment on every pull request, with coverage information, like this:

It is not difficult to configure all this in your project, but there are a few pain points along the way, so let me share with you a few tricks ..

Tricks of the trade ..

When we are talking about setup, CI, tests, build, and all those sort of things, there are a few principles that can help a lot in our journey:

• Baby Steps
• Start Small and build upon
• As soon as you reach a desired spot, commit (save your changes) and move on to next desired spot.
• Don't try to configure everything at once, this is the roadmap for failure.
• Test your configuration, constantly. Changes made and not tested are another recipe for disaster.

Following those simple principles can save you a lot of headache.

Danger only tricks ..

• Create another github Account
• Fork your repo
• Send PRs using this other account.

I've spent much time creating PR from branchs within my repository, and the are not treated by danger or travis as PR. Even though they are listed as PR's by github, this is a little confusing, at least i think so.

Wrapping up ..

This ends the third post of the series. Next one will address how to make better UIs using Sketch, Sketch for developers. Also will show hot to make your project's github page shine, by enhancing the README with badges, code coverage, pictures and all that cool and shiny stuff.

Our repo will get fancy .. $)

As always any thoughts, doubts or feedback are more than welcome. =)

Ps: If you like this post, share it on twitter, recommend it on medium, or both =). This really helps me to reach more people. Thanks a lot ..

Updated:** you can check the last part here.