Continuous Integration and Delivery for Agile Teams

In this article, I’ll walk you through the two main DevOps agile delivery methodologies: continuous integration and continuous delivery. I’ll also detail how to get started with them using Codeship.

A Look at the Recent Past of Software Delivery

In the not-so-distant past, delivering software was a risky, annoying, and time-consuming task. It was, most of the time, a shot in the dark. One of the greatest difficulties was coordinating the schedule of product releases. Things started to change with the advancement of version control systems.

The history of VCS can be divided in three generations:

• First - Only one person could be working on a file at a time.

• Second - Tools are a bit more permissive about simultaneous modifications, with one notable restriction: users must merge the current revisions into their work before they are allowed to commit.

• Third - The third generation tools allow merge and commit to be separated.

Here is a pretty decent timeline about the VCSs.

Popular tools like Git, Mercurial, Subversion, and many others proved quite efficient in versioning code. However, at the time, they still were unable to make the applications themselves bug-proof; it was difficult for developers to get into the habit of testing due to a lack of good testing libraries and tools to automate them.

As a result, software updates were released over the weekend, assuming that a smaller number of users would be affected in case of a bug. However, with code updating only every seven days (or even more rarely), it was hard to identify which code actually had created the bug. It could be ANY code that got created within the past seven days.

While facing code integration problems, there were also troubles relating to the system requirements/specifications. Not all software defects are caused only by coding errors. One common source of expensive defects was requirement gaps, e.g., unrecognized requirements that result in errors of omission by the program designer.

At the Agile 2008 conference, Andrew Clay Shafer and Patrick Debois began to spread the idea of “agile infrastructure.” It was an issue in need of a discussion because software delivery was still a slow process that brought tough days for development teams.

The term “DevOps” emerged through a series of “devopsdays” starting in Belgium/Ghent in the year 2009. Since then, there have been devopsdays conferences held in many countries around the world. DevOps is an evolution of Agile Development, which in turn is a generic term for several iterative and incremental software development methodologies, such as Scrum, Kanban, Lean Development, Extreme Programming (XP), and many others.

Moving on to the Advantages of Agile Development

The big advantage of agile development is that the code updates happen in very small parts. Every day, or even every few hours. So if there is code that is breaking something, it is a lot easier to identify which new code made the bug happen, because it must be something you worked on in the last two hours.

The crucial factors for the DevOps culture propagation are due to the adoption of two main agile delivery methodologies:

• Continuous Integration (CI)

• Continuous Delivery (CD)

Both came to change the way teams work together, allowing them to deliver reliable code in a quick and easy way. If, somehow, you are still part of that past, it is time to change the way you deliver software!

Vocabulary of agile development

After a little trip to the past, it is time to understand the meaning of these futuristic concepts:

• Continuous integration basically means that the developer’s code is synchronized with a shared mainline several times a day.

• Continuous delivery is described as the logical evolution of continuous integration: software can be released to production at any time.

• Continuous deployment is described as the logical next step after continuous delivery: automatically release the software into production whenever it passes QA (Quality Assurance).

We can see nowadays that a large number of companies have adhered to these agile methodologies. Nevertheless, some of them try to handle the agile workflow manually, which ends up not flowing as it should because someone needs to be responsible for updating the testing server; something that developers often don’t really like to do because they’d prefer to work on code for customers. That’s why there are specialized services out there today, like Codeship!

!Sign up for a free Codeship Account

Getting Started with Agile Development and Codeship

Codeship offers two products: Codeship Basic and Codeship Pro. I will talk about them more later in this article.

Registration and authentication

You can sign up with Codeship using email, GitHub, GitLab, or Bitbucket via OAuth:

After registering by email or through one of these source code managers, you are automatically using the Codeship free plan with the following features:

• 100 builds/month

• 1 concurrent build

• 1 parallel test pipeline

• Unlimited projects and users

Codeship's new UI

To bring a better experience to already existing users as well as new ones, Codeship redesigned its internal interface, and I was pleased to be one of the first to show you what’s new. For those who have been using this service for quite some time, this is your new dashboard. For those who are getting on board now, here is where you’ll find your project builds:

Initial instructions

In order to give you a better understanding and demonstrate how it would work in practice, I’ll go into detail, taking a simple to-do list API built using Rails. Don’t focus your attention on the application itself (if you do not use Rails). Focus instead on the steps I outline here for you. Through them, you’ll still be able to handle the setup for the framework you use in your day-to-day work.

Starting a new project

To start a new project, just click on the Projects menu. Click New Project, which will redirect you to this screen:

Click on the repository where your code is hosted. In my case, it’s GitHub. To connect your repository, just provide the URL to clone it (can be HTTPS or SSH) and click Connect:

In this part, you’ll choose the type that best fits your project requirements:

You can see that Codeship offers two products: Codeship Basic and Codeship Pro. Codeship Basic has preinstalled CI dependencies and is built to help you get started quickly and easily. Codeship Pro is focused on a lot of customization. It’s ideal if you want to use Docker, Kubernetes, and other technologies.

For now, we’ll go with Codeship Basic to give you a quick start. After selecting that option, we can preset the commands needed to correctly configure and install the application requirements:

Here, we can select the option that corresponds to the framework or language we’re using or define custom commands for unlisted technologies:

We’ll leave it the way it’s already set:

In this section, we’ll pass the command responsible for running our tests:

We’ll also leave this the way it is and save our progress. Click Save and go to dashboard. Now we can see our GitHub username and the repository on top of the Settings button.

Everything is done! The build will be triggered as long as we push some changes to our repository.

Continuous integration

I will perform a small implementation in my code:

# Gemfile
gem 'rubocop'

I just added the rubocop gem to check if my code follows good practices. Before commit it, I’ll add one more command to our test pipelines. By clicking Settings (under the repository name), I’ll change the Test Commands according to the image below:

This command (rubocop app test) will check for any code offenses inside the app and test directories. When a code offense is found, the build will fail. I will push this change to show you how the build is triggered. As we can see, after committing the new piece of code, the build started to run:

If you want to see the exact building progress, just click on it:

At the bottom of the build, we can see the command responsible for running the application tests. To see the console logs, just click on the command to expand it out.

Fortunately, all the tests passed, but after running all necessary commands, the build failed! But don’t panic, it’s easy to detect what happened.

Instantaneously, an email is sent reporting the failure:

If we look closely at the bottom of the email, we can see the command that has failed: rubocop app test. Actually, you can also be notified through services such as Slack, HipChat, Campfire, etc.

Clicking the command that is causing the error, we can see its output showing a lot of code offenses:

In practice, the programmer who was responsible for the build break would repair the code offenses, as well broken tests (in case they fail), and commit the code again. Of course, in order to get a view of the big picture, you’d need a simulation with two or more programmers. But this is enough to see that having a service that automates tests, notifications, and important commands for us makes it easy to take control over the code that is being released.

Continuous delivery

My little API is published in Heroku, a cloud platform as a service (PaaS) that lets companies build, deliver, monitor, and scale apps, bypassing infrastructure headaches. I just created three simple records as a demo:

Setting up deployment

Let’s continue exploring our settings screen. This time, we’ll click Deployment on the left-side menu.

As you can see, we can choose which branch to raise for production when the build is green. In my case, I am using the branch controller. After picking up the branch’s name, we should click Save pipeline settings to go ahead. Now we must select the server where the application is hosted.

All the information needed to configure the integration with your server is very simple and easily found.

Just below the form, there’s a link to help us find the Heroku API key:

There are many more configuration options, as you can see in the image below. For now, I will just fill out the Application Name and Heroku API Key.

To save these settings, click Save Deployment Changes.

All ready! We just need to push another commit to start continuous integration, as well continuous delivery and deployment.

Pulling the trigger

This time, I will add a new field to my table. I’ll call it created_by, where the name of the person that created the record will be registered.

rails g migration add_created_by_to_todos created_by:string && rails db:migrate

Now, I will return to the Settings screen on Setup Commands to comment bundle exec rake db:schema:load and uncomment bundle exec rake dd:migrate.

rake db:schema:load is great for the first time you put a system in production. After that, you should run migrations normally. In fact, Heroku allows us to do this manually via command line, but for everything we automate, we will have one less concern to worry about.

After we add any modification on Setup Commands, we should click Save and go to dashboard. As expected, the build was triggered after my commit:

After running the build, happily, things worked out:

Taking a look at the output of the command I added, I can see that everything worked as expected:

And lastly, make sure that everything really happened the way it should have:

The field was successfully added to the production environment table!

Tutorial Bonus

There are several ways to be notified about the build status of your application, but let’s end by learning how to add the Codeship badge to the README. In Project Settings, click Notification and at the bottom of the page, you’ll see this:

I’ll add the Markdown Syntax, but there are other options as we can see. After copying and pasting the desired option into your README file, you’ll be notified according to the images below:

DevOps Business Benefits

The challenges that emerge on the business horizon make us understand the importance of investing in a solid IT infrastructure where development processes can flow in a more agile and innovative way.

The 2014 State of DevOps report showed that companies successfully implementing DevOps methodologies led competitors in almost every relevant metric. Two of the highlights of this report are that companies that use DevOps are twice as likely to exceed profitability, market share, and productivity goals, and have 50 percent more market value and growth than competing companies.

Conclusion

One of the main objectives of this brief introduction to continuous integration and delivery was to help your team gain insight into the advantages offered by agile development techniques. Of course, there’s still a lot to explore, but let's finish here to keep the article from getting too lengthy. I’ve shown you the essentials, but you can easily walk through the Codeship's intuitive interface and discover more incredible DevOps features!