Rultor.com, a Merging Bot

You get a GitHub pull request. You review it. It looks correct—it's time
to merge it into master. You post a comment in it, asking
@rultor to test and merge. Rultor starts a new
Docker container, merges the pull request into master, runs all tests and, if
everything looks clean—merges, pushes, and closes the request.

Then, you ask @rultor to deploy the current version
to production environment. It checks out your repository, starts a new Docker
container, executes your deployment scripts and reports to you right there in
the GitHub issue.

Why not Jenkins or Travis?

There are many tools on the market, which automate
continuous integration and
continuous delivery (let's call them DevOps).
For example, downloadable open-source
Jenkins and hosted
Travis
both perform these tasks. So, why do we need one more?

Well, there are three very important features that we need for our projects, but
we can't find all of them in any of the DevOps tools currently available on the
market:

Merging. We make master branch read-only in our projects,
as this article
recommends. All changes into master we pass through
a script that validates them and merges.

Docker. Every build should work in its own
Docker container, in order to simplify configuration, isolate
resources and make errors easily reproducible.

Tell vs. Trigger. We need to communicate with DevOps tool
through commands, right from our issue tracking system (GitHub
issues, in most projects). All existing DevOps systems trigger
builds on certain conditions. We need our developers to be able
to talk to the tool, through human-like commands in the tickets they are working with.

A combination of these three features is what differs
Rultor from all other existing systems.

How Rultor Merges

Once Rultor finds a merge command
in one of your GitHub pull requests, it does exactly this:

Reads the .rultor.yml
YAML configuration file from the root directory of your repository.