Semaphore App. Ruby on Rails. Continuous integration / delivery

Foreword

Having run through Habr, I surprisingly did not find a single article about a full-fledged team workflow using various magical quirks in the spirit of Continuous Integration & Continuous delivery, various Github - 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 experience, to talk about various buns that make life easier for the team working on one project together, how this can be combined into one streamlined system and reduce the number of unpleasant feelings in the lower back during time of work on the project.
')
So, under the cut - analysis of CI service SemaphoreApp, a little about integration with other services and other pleasures that simplify our lives.

The essence

You know, I will not explain in detail what CI is, why it is needed, and other general things, because many gentlemen had already explained them to me, and well, clearly, let's say, here: “Introduction to Continuous Integration” .

And now, to the main point, let's connect our Rails app to 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 uncle will brag to us how cool it is to deploy for 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 you want to build.



We will be offered to make the initial project settings. Of the proposed languages ​​- Ruby, Clojure, JS, PHP, Go, and the mythical language "Other."

There are variations from the database used.



And - everything. You have your CI, 5.times {puts 'hooraaay!' }



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

And, by the way - integration with GitHub and Bitbucket has already happened. If your build fails, you can still make a merge pull-request. And get over the ears from the team leader, for the boneless build.



By the way, if you have conflicting branches, then after the build, even the last one, Semaphore will not allow you to confuse your conflicting PR until you do git rebase -i your_integration_branch, and fix all conflicts.

Well, if you have the green light, and, as in the right team, you were reviewed by your pull-request, and set to OK - you can press the cherished button and brag on the stand-by next day.

Communication

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

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

A small example with all the integrations that I did in the same room Hypchat.



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

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



Build settings, configs, ENV vars, repository information, you can set priority branches for builds, run builds on a schedule (did not think of why), deployment (about which later), the Notifications tab, which, with a couple of copy-pasts, sets up alerts to you by email / hipchat room / slack room / another_where, and so on.

For Hipchat, you just need to know the room name, or room ID, and token, which are easily generated in the HipChat settings. It is worth driving - 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 a note of Continuous Deployment with Heroku.

That purple message in the picture with integrations in HipChat was the notification from Heroku about the successful delay. Although, I didn’t do anything with my hands, I just had my pull-request, which was reviewed. Semaphore did everything for me, and I can imagine myself the successful uncle who offered us to use this service.

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

In truth, it would take me less time to push for styling with Continuous Delivery than to describe the workflow.

Let's start with 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 every_successful_bild, which means if the build is not successful, it will not go anywhere, and the second way provides you with a briefcase with a red button, by pressing which the build will be sent to your server. We are lazy, besides, our server should be considered for staging, and auto-warming will also be used for staging. For prodakshen better already on the button.

Then we will be offered to choose a branch for deployment and enter the Heroku API key. And then it all is able to.

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

I hope someone will find this useful.