Semaphore App. Ruby on Rails. Continuous Integration / Delivery

Foreword

Having run around Habr, I surprisingly did not find a single article about a full-fledged team workflow using various magic quirks in the spirit of Continuous Integration & Continuous delivery, various Github integrations - HipChat (Slack) - CI - Staging and Production via Continuous Delivery, and other things, although I may just not be able to search.



But still, I wanted to share my, albeit little work experience, talk about various goodies that make life easier for the team working on the same project together, how all this can be combined into one debugged system and reduce the amount of discomfort in the lower back in project work time.

So, under the cut - the analysis of the CI service SemaphoreApp, a little about integration with other services and other joys that simplify our lives.

Essence

You know, I will not explain in detail what CI is, why it is needed, and other general things, because many gentlemen have already explained them to me, and it’s clear, clearly, say, here: "Introduction to Continuous Integration . "

And now, to the main thing - connect our Rails app to the Semaphore.

Our great task is to go through an intuitive registration, but we still go through it, with comments and pictures.

Sign up

We go to semaphoreci.com, and the cool guy boasts to us how cool he is deploying to production.



We have a choice between GitHub and Bitbucket. In fact, Semaphore supports a bunch of Atlassian products - Bitbucket, Hipchat, Jira.

Not so bad.



Then just select the project and the branch that you want to build.



We will be offered to make the initial settings of the project. Among the proposed languages ​​are Ruby, Clojure, JS, PHP, Go, and the mythical language “Other”.

There are variations with the database used.



And that's all. You have your own CI, 5.times {puts 'hooraaay!' }



In fact - the simplest thing is to just poke buttons. The complexity of all integration with other services will depend on your ability to press CTRL + C and CTRL + V. Well, and read in English. The level of confident PC user, accountant-translator.

And, by the way - integration with GitHub and Bitbucket has already happened. If your build failed, you can still do merge pull-request. And get over the ears from the team lead, for the boned build.



By the way, if you have conflicting branches, then after the build, even the one that passed - Semaphore will not let you hold your conflicting PR until you do git rebase -i your_integration_branch and fix all the conflicts.

Well, if you have a green light, and, as in the right team, they did a review of your pull-request and set OK - you can press the treasured button, and boast on the next-day stand-up.

Communication

So, let's move on to the next part of our system - to notifications about successful / unsuccessful builds, and just about intra-team communication.

The mass of variations, I suggested just HipChat or Slack. Why - both are free, Slack looks nicer, but limited integration (only 5), their smallness is smaller than that of HipChat. HipChat - unlimited integrations, but in general - the same Slack, only it looks boring. Not for trendy startups.

A small example with all the integrations that I did in one room of Hipchat.



Actually, there are all the logs of what happened with the project. And this is far from all that can be integrated there. Errors with Airbrake, NewRelic alerts, and many many more.

Now we can see what Semaphore can do. List of settings in the studio.



Build settings, configs, ENV vars, information about the repository, you can set priority branches for builds, launch builds on a schedule (didn’t come up with why), deployment (about which a little later), the Notifications tab, which sets up notifications for email / hipchat room / slack room / somewhere else, and so on.

For Hipchat, you only need to know the room name, or room ID, and token, which are easily generated in the HipChat settings. It’s worth driving in - and the notification service is ready. Easy

Well, of course there are webhooks if you need to set up alerts somewhere else.

Continuous deployment

But perhaps it’s worth completing my story on the note of Continuous Deployment with Heroku.

That purple message in the picture with HipChat integrations was a notification from Heroku about a successful deployment. Although he didn’t do anything with his hands, he simply controlled my pull-request, which passed the review. Semaphore did everything for me, and I can imagine myself as the successful uncle who suggested we use this service.

Let's say we already have a Rails application, and there is a Heroku server, and our workflow is to make a branch, write a feature, write tests, run tests in a branch, run a branch in integration, run all integration tests. If successful - git push heroku.

To tell you the truth, it would take me less time to push to staging with Continuous Delivery than to describe workflow.

Let's start with the integration - settings, Deployment tab, Add Server. We are offered a choice.



I decided on heroku, your choice is yours. Then we are offered to choose the type of deployment: automatic or manual. The first deployment is each_successful_build, which means if the build is not successful, it won’t get anywhere, and the second way provides you with a briefcase with a red button, by clicking which the build will be sent to your server. We are lazy, and besides, our server is considered to be staging, but for staging it will also be auto-depleted. For production, it’s better for a button.

Then we will be asked to select a branch for the deployment and enter the Heroku API key. And then it can do everything by itself.

You can also install the heroku add-on - Deploy Hooks, which has a HipChat hook that will notify you of successful or unsuccessful deployments. Although there will be no unsuccessful deployments, if the build fails, I repeat - there will be no deployment.

I hope this is useful to someone.