Continuous Integration for Ruby on Rails

Continuous Integration for Ruby on Rails?

I just went through the options here and thought I'd roll them up as of late 2011.

Integrity

After a near-death experience that left the still-linked-to website with outdated information and downed the demo site, this project has a spark of life again. But the documentation hasn't moved on, and lots and lots of the steps in the tutorial are just plain broken; I had to change references to gems, build some things out of band, and then I still couldn't get it working.

Cruise Control.rb

Dead simple: you just download it, run a command line to add your project (there is no UI for doing so), and run the Rails app. But there's no UI for editing your project, either, and there's no real integration with build artifacts aside from displaying links to them: you get no graphs of tests run, no trend lines, etc. I also had to adjust the routes.rb file to get the code linking working (the resources :projects line needs to move below all the other non-default routes).

TeamCity

This looks awesome, but the pay scale seems out of whack. 3 agents free and then when you're dependent you need to dole out hundreds of dollars. Personal Builds looks great, but don't have the budget.

Jenkins (née Hudson)

This is a Java stalwart and it is loaded up with a thousand options, so the UI is confusing and it's a chore to set up your projects. But once you set it up you get a whole lot of plugins that can pull from most anywhere, run most anything, and report most everything. The OS X Installer points Jenkins at /Users/Shared/Jenkins/Home but fails to create that directory or chown it to daemon (which is uses by default, and you should change to a new jenkins user so you can set up GitHub integration).

Others

I didn't really try these, but thought I'd mention why:

• CI Joe wants to own the GitHub repo more than I want it, and its creators aren't even using it; they're on Jenkins.
• Cerberus seems neatly small but doesn't have a UI and doesn't automatically publish build artifacts where others can see them.
• BigTuna seems to be a CruiseControl.rb clone without the (already minimal) community support.
• Bamboo looks really neat if you use JIRA and BitBucket, but we use neither. It does deploys but we already have those set up in Capistrano.

The Choice

We went with Jenkins, but I really wish one of the lighter-weight solutions had worked out.

Continuous Deployment

Usually people have 2 branches, one for staging/development which deploys on the staging server and one for production which deploys to the production branch

once your staging branch is tested and ready for deployment on production, you could create a pull request from staging to master (or just merge it locally and push it) and then the CI server should detect a new version on the master branch and then deploys it to the production server.

What is the best CI server for Ruby on Rails Web Applications?

http://cruisecontrolrb.thoughtworks.com/ - really simple and yet pretty powerful (especially because of its extensibility) CI server written in ruby with a target on ruby-based projects. Configs are ruby based, really well documented.

Which Continuous Integration service should I choose for average Rails project?

I used Vexor and it left good impression. Take a closer look at it, because:

1. Vexor really allows you to run as much threads as you want.
2. As I remember, it has some free minutes each month, so you can try it for free.
3. Vexor is compatible with .travis.yml.
4. We had a similar by size project and price was less than 50$.

Good luck!

Proper continuous integration and continuous deployment with Git and Heroku

We use Integrity. It is a pretty simple solution - it won't do everything under the sun, but it's quite easy to set up and handles the most common use cases/features. It's also pretty easy to hack on, if you want it to do more.

Integrity states:

Heroku is the easiest and fastest way to deploy Integrity.

However:

NOTE

It isn’t possible to access repositories over SSH on Heroku

This is because your Integrity app will need an SSH key. It's not impossible, but definitely a few hoops to jump through. You'll need to give Integrity a private key and put it in the app, and then hack Integrity to use that ssh key when it initiates the git clone.

Of the things you listed, the automatic deploy is probably the thing most people would not expect their CI server to do (and Integrity does not provide out of the box). You'll need to configure git to use that ssh key and initiate a git push from the proper location (the checked out repository).

Unfortunately I don't know the details of how to do this--we actually run Integrity on a VPS.

Tips and steps for setting up ruby on rails continuous integration server with github integration

For CI server you can use CruiseControl developed by ThoughWorks

. Its open source as well . You can get it from github as well.

And pretty much simple to set up only takes 10 min to setup and as its written in ruby its pretty much simple to hack and customize to as per your need .
Reply me if you find anything problem in setup CI
Thanks

Rails app, Continuous Integration/Deployment Environments

Running any tests on PROD environment as you said

seems the only logical answer

but is not quite true. There are risks that your tests can seriously damage the actual environment/application to a point where you'll face a recovery option. After all the dark side of testing is to show/find that your software has not only minor bugs and it is working not as expected.
I can think of at least these 'why not test production' considerations:

• when the product is launched, the customer rely on it. Expecting that your software is working ()being already tested). Your live environment should do its job and not be loaded with tests. If the product misbehaved (or did not perform), the technical team have to be sent to to cover the damage, fix the gaps and make it run hassle free. Now this not only affected the product cost, but delayed the project deadlines in a major way. This will make a recursive effect at the vendors profits and next few projects.

• the production or development team when completes a product development at their end, have to produce this test environment for testing team prior to loading their newly developed product on that environment for testing.

To me, no matter that you

also have staging and production environments

it is essential to use the Test one accordingly. Further more Testing environment should be (configured) as close as it gets to the Production. Also one person could be trying to test while another person breaks the thing that he has been testing. With out the two being separate their is no way to do proper testing.

Just to be full answer, your STAGE environment can have different roles depending on the company.
One is that it can be the QA/STAGE environment that has an exact copy of production which is used for both QA and system testing (testing of the system when a lot of updates/changes or upgrade is going to go into production).

UPDATE:

That was my point too. The QA environment should be a mirror of the PROD. Possible solution about your issue with caching/pre-loading files onto staging/production is creation of pre-/post-steps .bat (let's assume) files.

In our current Test project we use this approach. In pre-steps we set-up files needed for test execution (like removing files from previous runs and downloading latest copies/artifacts). In post-steps we set up reporting files needed.The advantage is that your files will be collected and sync before every execution.

About the

not on the same physical hardware

in my case we support dedicated remote Test server. Advantages are clear, only thing that you need to be considered is that it'll require maintenance (administration).

---

Related Topics