Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible.
Continuous Deployment follows your tests to push your changes to either a staging or production system. This makes sure a version of your code is always accessible.
I need to write tests, know that my tests cover everything, run those tests often and deploy when ready, and know that my dependencies do the same, and collaborate on fixing bugs.
class DogTest < Test::Unit::TestCase
setup do
@dog = Dog.new
end
def test_barks
assert_equal "woof", @dog.bark
end
def test_doesnt_bark_when_dead
@dog.die
assert_raises DeadError do
@dog.bark
end
end
enddescribe Dog do
before(:all) do
@dog = Dog.new
end
context "when alive" do
it "barks" do
@dog.bark.should == "woof"
end
end
context "when dead" do
before do
@dog.die
end
it "raises an error when asked to bark" do
lambda { @dog.bark }.should raise_error(DeadError)
end
end
endFeature: Dog barks
Scenario: A dog can bark
Given a dog
When the dog barks
Then the dog should "woof"Given(/^a dog$/) do |dog|
@dog = Dog.new
end
When(/^the dog barks$/) do |dog|
@bark = @dog.bark
end
Then(/^the dog bark should (\w+)$/) do |action|
@bark.should == action
endclass UserFlowsTest < ActionDispatch::IntegrationTest
test "login and browse site" do
# login via https
https!
get "/login"
assert_response :success
post_via_redirect "/login", username: users(:david).username, password: users(:david).password
assert_equal '/welcome', path
assert_equal 'Welcome david!', flash[:notice]
https!(false)
get "/articles/all"
assert_response :success
assert assigns(:articles)
end
endclick_link('id-of-link')
click_link('Link Text')
click_button('Save')
click_on('Link Text') # clicks on either links or buttons
click_on('Button Value')
fill_in('First Name', with: 'John')
fill_in('Password', with: 'Seekrit')
fill_in('Description', with: 'Really Long Text...')
choose('A Radio Button')
check('A Checkbox')
uncheck('A Checkbox')
attach_file('Image', '/path/to/image.jpg')
select('Option', from: 'Select Box')
page.has_selector?('table tr')
page.has_selector?(:xpath, '//table/tr')
page.has_xpath?('//table/tr')
page.has_css?('table tr.foo')
page.has_content?('foo')
within("li#employee") do
fill_in 'Name', with: 'Jimmy'
endUses Spec-like expressions for tests on the Javascript side of the Rails application. Utilizes Capybara to drive tests using the browser (through selenium, or webkit).
describe('when the radio is selected', function() {
beforeEach(function() {
$('#payment_cc').attr('checked', true);
});
it('should do something', function() {
// Assert that the submission went the way you wanted it to
});
});[![Konacha in action][konacha-poster]][konacha-youtube] [konacha-youtube]: http://www.youtube.com/watch?v=heK78M6Ql9Q [konacha-poster]: https://github.com/jfirebaugh/konacha/raw/master/images/youtube.png
Automated code review that analyzes every commit, branch and pull request.
Use case:
I am a good developer that wants to make sure I wrote good tests and avoid some anti-patterns.
Shows which parts of your code aren’t covered by your test suite.
Use case:
I am a good developer that wants to make sure I didn't miss testing any of my code.
Travis is a continuous integration platform that watches your Github repository for commits, tries to build the branch, and runs rake for you. The results are emailed to you as reminders.
- Cloud-hosted
- Very simple
- Plays well with Github and Heroku.
Use case:
I am a good developer that writes tests and contributes to a smaller application. I need to be reminded that all my tests pass as I code on features, and I don't want to have to remember to deploy my production/master branch to my cloud service (like Heroku).
Travis CI is written in mostly Ruby, with workers in Go.
Does everything that Travis can do, except it's been around longer, looks a little trashier, but is better for enterprise systems that are private and need more customized build paths (like having your own build servers).
- Locally-hosted
- Highly customizable
- Getting kinda old.
Use case:
I am a good developer that writes tests and contributes to a large application with its own build servers. My team needs to be aware of which branches and pulls are ready to be merged safely, and I don't want to have to remember to deploy to my environments.
Jenkins CI written in Java.
A good mixture between Jenkins and Travis. Does everything Travis does, looks great, and caters to the enterprise market a bit better than Travis. Almost a "new" Jenkins, but entirely hosted. Free option has one build server; Paid options have many hosted build servers.
- Cloud-hosted
- Customizable
- Can be simple, but has more options.
Use case:
I am a good developer that writes tests and contributes to a medium/large application without local build servers. My team needs to be aware of which branches and pulls are ready to be merged safely, and I don't want to have to remember to deploy my production/master branch to my cloud service.
Circle CI written in Clojure.
Example:
I am a good developer that writes tests and contributes to a medium/large application. My company has many applications that work together, and they need to be deployed to our environments in a consistent manner. Since no one developer knows the entire the deployment process, I need to corral these cats so they don't burn the house down.
Distelli is written in Ruby.
Pulls your GitHub issues and pull requests into a project-management view and tool (BACKLOG, READY, IN PROGRESS, DONE) that encourages collaboration. You don't have to manage Waffle.io, instead you'll just work with Git and the GitHub issues/PRs.
Also a GitHub competitor (like BitBucket), but has a heavy focus on collaboration. Imagine if Slack and GitHub had a baby on your local server.


















