Semaphore Blog

News and updates from your friendly continuous integration and deployment service.

Ruby Version Usage in Commercial Projects, 2015 Edition

Get future posts like this one in your inbox.

Follow us on

Continuing our modest tradition of publishing an annual report on Ruby versions used for private projects on Semaphore, we’re presenting you with the results for 2015.

Ruby version usage for commercial projects on Semaphore

Since we published last year’s report, we’ve seen a steady flow of new Ruby releases according to the decision to adopt the semantic versioning policy.

Given the multitude of Rubies 2.1.x and 2.2.x now available, we’ve decided to present them grouped as such in the overview chart above.

It appears that once a team has managed to cross the chasm between 1.9.x and Ruby 2, adopting newer versions is relatively easy. Today, 79% of all commercial Ruby projects are using some flavor of Ruby 2, up from 51% last year. The following chart shows the adoption cycles for each version:

Ruby version adoption year over year on Semaphore 2015

Of course, life is complicated, and old versions don’t just go away. A closer look shows increasing fragmentation in Ruby versions used among developers:

Ruby version fragmentation in commercial projects on Semaphore 2015

As for Rubies 2.1.x and 2.2.x, even though it is now much easier to upgrade to a newer micro version, zooming in the data shows that usage is quite fragmented too:

Ruby 2.1.x and 2.2.x usage on Semaphore 2015

What’s your team’s approach to keeping up with new Ruby releases? Feel free to discuss in the comments below.

Introducing Semaphore Insights: Find Test Files That Slow You Down

Today we’re happy to announce Semaphore Insights, a new part of Semaphore with the goal to give you useful, actionable feedback on your continuous integration process.

Semaphore Insights: Find slow test files

As developers we all want our builds to finish fast, but sometimes we introduce bottlenecks to the test suite without realizing it. This can be by writing tests that make excessive database calls or similar inefficient use of resources. Just like we understand the need for refactoring the application code, we need to find time to refactor and improve our test code too.

So the first available feature in Semaphore Insights is a report on your slowest test files. It displays all test files which take more than a minute to run, and if none such are found then the slowest five by default.

Semaphore Insights: Example list and continuous integration history chart for Cucumber test files

We have found that a minute is a sensible threshold in large projects — more than that is usually a smell and we recommend looking into the code or considering to split the test file. The benefits are both a faster feedback loop your development workflow and parallel execution in CI. For example, if you have a test file that takes 4 minutes to complete, then your whole build cannot complete sooner than 4 minutes, plus some setup and teardown operations that may exist for your project.

How to enable Semaphore Insights

On your project page, click on “Find slowest test files” link and then enable the feature for your test framework. That’s it — the report will be ready after your next successful build. To see the chart of historical performance, just click on a test file to uncover it.

In order to gather the necessary information, Semaphore inserts some additional formatting options to the corresponding test framework’s configuration file, such as .rspec. That should not affect your build in any way, but if you think it does, report it through a support message and we’ll investigate.

We will be rolling out this feature to all users over the next couple of days.

Semaphore Insights currently supports RSpec 3 and Cucumber. If your testing framework is not supported but you would like it to be, we want to hear from you.

We hope that you will find Semaphore Insights useful. If you have any feedback on it, or even have ideas where it could go next, please get in touch.

Happy building!

Platform update on November 24th

The upcoming platform update is scheduled for November 24th, 2015.

Chromedriver gets an update with version 2.20 which supports Chrome versions v43-48.

Git has been updated to version 2.6.3.

Java gets two version updates with 7u85 and 8u66.

PHP receives an update with version 5.6.15.

RethinkDB gets an update with version 2.2.0.

RubyGems has been updated to version 2.5.0 for all Ruby versions supported by Semaphore.

New things

Elixir 1.1.1 has been added to the platform. Until this version isn’t added to the language settings for your project, adding kiex use 1.1.1 as a setup command will activate it for your builds.

Firefox 38.4.0esr has been added along with a tool for switching between different versions. To change the currently active Firefox version, add change-firefox-version <version> as a setup command. Valid versions are 38 or esr for Firefox 38.4.0, and 34 or default for Firefox 34.0. The default version is 34.0.

Node.js 5.0.0 is now part of the platform. To use it in your builds during the release candidate period, add nvm use 5.0 as a setup command in Project Settings. On the day of the final release of the new platform, Node.js 5.0.0 will be selectable in Project Settings too.

Python 3.5 has been added to the platform.

Trying the new platform

You can evaluate the new platform right away by selecting Ubuntu 14.04 LTS v1511 (release candidate) from the Platform section of Project Settings. We encourage you to try it out, so that we can fix the issues you may encounter until the final release on the next Tuesday.

Changes in the final release

RethinkDB gets an update with version 2.2.1.

RubyGems 2.5.0 has been rolled back to version 2.4.8 due to incompatibilities with some gems.

A full list of changes is available in the platform changelog.

Bootstrapping a New Product a Developer Interview with Rupeal

In the “Developer Interview” series we talk to developers from some of the companies using Semaphore to find out how they work, and share their insights with you. This time we had the pleasure of talking with Pedro Pereira Santos, team leader at Rupeal, a Portuguese company that has two completely bootstraped products behind them.

Tell us about your role and responsibilities at RUPEAL.

Pedro Periera Santos ClanHR

I’ve been a team leader for a couple of years. I work together with the team on building new features, planning our product’s architecture and improving our development process. When I moved to the company, I started doing Ruby on Rails on InvoiceXpress, an online invoicing system. Three years later, I am now bootstrapping again with a new product: ClanHR.


What does your product design and development workflow for ClanHR look like? Any important lessons from the past you’re applying to your new product?

We have a product owner that does market research and builds proper specs. We use marvelapp to build interactive mockups, and we show them to clients for product fit. Next, our designer builds mockups of the features and iterates on them until we are happy with it. The designer is proficient in building ReactJS/HTML/SasS applications, and she can build a visual representation of the features in ReactJS. This means that we should have proper specs and already available pages and React components when the features get to the developers. The developers just need to add functionality.

ClanHR Dashboard

All code is on GitHub, and all changes must be made via pull requests. When a pull request is available, the entire team must review it and OK it. As soon as the branch is created, Semaphore steps into action: it bootstraps the app, checks dependencies, runs the tests, and generates a package. If everything is working, the pull request will be marked as good to merge.

When we merge the pull request, Semaphore automatically deploys the master version to the staging environment. This means that we get to staging very quickly. This is important because the product owner and the designer can fine-tune the features quickly, and it saves us time spent on deploying.

This is in contrast with our other product. Due to several legacy issues we can’t be this agile, and end up spending a lot of time waiting around for things to happen.

Is your team doing TDD or BDD? How would you describe your role of Lead Code Detonator in the process of product development?

We mostly do TDD. When the developers get a feature they need to implement, we usually team up to think things through together. Even if it’s just going to be one developer to implement the feature, this analysis phase really boosts our productivity. Next, the developer starts coding. We are working with Clojure, and have a very fast workflow with fast unit tests. We implement endpoints on the services without booting a server, we just create tests and scenarios until we have the server side of the feature done.

The last step is to go to the frontend and connect everything.

ClanHR Team Photo

What tools and guidelines do you use to write tests across your application stack?

Because we rely so much on TDD, our tests’ feedback cycle needs to be pretty fast. When we are testing code with dependencies like the database, we create a gateway for the actual database, and an in-memory implementation that mimics the database gateway. We then implement and test this very fast environment again. However, we also want to test all that we are doing against the database gateway. We can do that on our development machines, but usually we leave that to Semaphore. When we push, Semaphore runs the tests two times, one for each gateway.

We also try to focus on gateway-less scenarios. Using functional programming and focusing on pure functions allows us to build tests that just check data and have no dependencies.

All services are tested as a unit, and they don’t communicate with other services during the test process. However, we use Nightwatch to test features on the frontend. These are very high-level tests that touch all parts of the application: the frontend, services and the database. They are very slow, so we try to keep them small and only create scenarios for key workflows in the application.

You mentioned to us that your full tests went down from 40 minutes on our machines to 15 minutes on Semaphore. How did this happen?

At one point, our full test suite for InvoiceXpress would take about 40 minutes to complete. This was on our development machines, and we started running the full suite only before merging a branch. However, on Semaphore, the full build took 30 minutes to do the same! And then we enabled parallel execution and split the unit tests from the Cucumber tests, and the full suite took 15 minutes.

“The feedback cycle improved so much that we started pushing to master to verify that the tests were passing.”

ClanHR Team Photo

How does Semaphore help you achieve your goals?

Semaphore is very easy to configure, and also very powerful. It enables us to easily implement a continuous delivery process without having to worry much about the way to implement it. Any team member, even the non-programmers, can make changes, and as soon as the branch is merged, it will take only a couple of minutes for them to see their changes live.

The support is also great and fast, and always tries to come up with solutions for our weird ideas. The whole company feels that Semaphore is a valuable business partner.

Introducing Easy Continuous Deployment to Amazon S3

Amazon Simple Storage Service (S3) is a part of AWS that provides an API and a simple web interface to store and retrieve any type of data from anywhere on the web. An S3 bucket is conceptually similar to an API driven file folder.

One of the features of AWS S3 is that you can also use it to host static websites. The Semaphore blog, for example, is hosted on S3. Today, we’re happy to announce an integration which makes it easy to automatically build and deploy static websites as you push new versions to your Git repository. It works great for all other kinds of content too.

Continuous deployment from GitHub via Semaphore CI to Amazon S3

Similar to our continuous deployment integration with AWS Elastic Beanstalk, which we launched last week, our goal with S3 has also been to simplify the process as much as possible. Semaphore can detect your existing S3 buckets and also lets you create new ones, all without visiting the S3 web interface. There are also options to enter your custom site building commands and set the index page of your website. The brief screencast below shows this quick setup process.

You can tell Semaphore to automatically deploy your application from a selected branch whenever all tests pass, but you can also choose to do it manually yourself. At any time, your team will have a shared deployment history and uniform way to publish your website online.

If you don’t have any experience with static website engines, staticgen.com provides a good overview of the most popular options in various programming languages.

For more detailed help in getting started using our new feature, please see the related documentation page which explains the basics behind deploying to S3 and how to retrieve your AWS credentials.

We hope that the new Semaphore integration with Amazon S3 will help improve your continuous deployment workflow. Happy building!

Continuous Deployment with Phoenix 1.0 via Semaphore

By Josh Adams of ElixirSips

I have an application up at http://elixirfriends.com. It’s a Phoenix-based Elixir webapp. Since Phoenix hit 1.0 this week, I thought it would be a good time to outline how you can set up Continuous Integration and Deployment of a Phoenix-based application using Semaphore. Let’s get started.

Project Details

So this project lives at on GitHub at knewter/elixir_friends. It’s a pretty standard Phoenix application, and it uses a React-based frontend to render the views after talking to the API to get the data. One particularly fun piece of it is the ImageTweetStreamer, which gets a stream of tweets matching a given search term, filters out those that don’t have images, and stores them in the database if they haven’t already been stored. Using one of Phoenix’s more interesting features, Channels, we broadcast any newly-stored tweets to the frontend for real-time addition to the page. We then run this as a supervised Task when our application starts.

Alright, so we have our application and you have a good feel for how it works now. Where does Semaphore come into play?

Continuous Integration

Well, I’ve been writing software for long enough that I’m now of the opinion that if you don’t have tests you haven’t really written anything. Consequently, I have a few tests to verify that my API works as expected. Here’s the controller test, which very basically confirms that my API returns posts in our system.

But what good are tests if you aren’t running them? I run my tests as I’m building my software, but I also know that if I don’t automate things I’m not likely to be as rigorous as I’d like. To avoid merging Pull Requests that break the tests, I’d like to automatically run the tests on any Pull Request. In the past I’ve used Jenkins for this sort of thing, but honestly running my own infrastructure for CI is a bit time-consuming, and I’m especially unlikely to set it up for open source projects. Semaphore provides a very simple means to set up CI for anything ranging from small open source projects to large private projects.

Setting up Semaphore for Continuous Integration

Adding a Project

Once you’ve logged into semaphore, there’s a link in your dashboard to add a new project.

Add a new project

Selecting Your Repository Host

Semaphore provides nice integration with various potential repository hosts. Our app is on GitHub, so we’ll pick that:

Select Repository Host

Choose Repository

Semaphore now connects to GitHub via OAuth to list your repositories, and you can just click on the repository you want to set up CI for:

Choose Repository

Select Branch

Your branches will be listed, and you can choose the branch you care about:

Select Branch

Select Account

Next, you choose your Semaphore Account. I only have one:

Select Account

Analysis

This is one of the coolest features of Semaphore. It will analyze the project to determine which kind of project it is.

Analysis

Review the Build Plan

Since Semaphore knows it’s an Elixir project, it has a very good default plan in place. You’re provided with a screen to make any changes to the build in case your project requires additional setup.

Review the Build Plan

First Build

Once you’ve OKed the Build Plan, your first build is kicked off immediately:

First Build

Our First Build Fails

Our first build fails…you can see in the browser why it failed:

Build Fails Due to DB Settings

Set Up Database Configuration

The problem was due to our database connection failing. Semaphore provides you with a username and password to interact with your database in two environment variables:

  • DATABASE_POSTGRESQL_USERNAME
  • DATABASE_POSTGRESQL_PASSWORD

We modify our test environment for the Phoenix application to use these environment variables if they’re present:

Setup DB in Phoenix

Successful Build

When we push that fix up, Semaphore immediately kicks off the new build. This time it passes, because we’re able to talk to the database successfully:

Build Success

Setting up Semaphore for Continuous Deployment

So now we’ll know when our builds fail, which is very good. As soon as I’ve got Continuous Integration set up on a project, though, I prefer to immediately add Continuous Deployment. I find that automating my deployment from the master branch is a great way to avoid getting into the situation where all of my deployments require manual intervention. If you always have to support automated deployment, then you’re going to write better software and be more careful about what makes it into the master branch. Semaphore provides extremely easy-to-use support for adding Continuous Deployment.

First off, I set up my app so that I could deploy it with Heroku. For most of my applications I don’t use Heroku, but I definitely prefer to deploy open source and community-focused apps to Heroku because it makes collaboration a lot easier since I don’t have to manually manage permissions to my servers. Once I set that up, I set out to use Semaphore for Continuous Deployment for the first time.

Set Up Deployment

If you visit the projects page in your dashboard, there’s a button to that says “Set Up Deployment.” Seems like what we want, so let’s click that.

Set Up Deployment

Choose Deployment Type

Next, we’re presented with a choice of deployment types that are supported out of the box. We have a Heroku application, so we’ll choose that.

Choose Deployment Type

Select Strategy

Now we’re prompted to choose our strategy. We can pick either Automatic or Manual, but our whole point is to have Continuous Deployment so we choose Automatic.

Select Strategy

Choose Branch

Now we can pick the branch we want to deploy on success. We pick master, which happens to be our only branch at the moment anyway.

Choose Branch

Paste API Key

Since we’re deploying to Heroku, we’re not prompted for our Heroku API Key. There’s a handy link that takes you right where you need to go to get it from your Heroku Dashboard.

Paste API Key

Pick Heroku Application

We’re now presented with a list of our applications on Heroku. We’ll pick elixir-friends.

Pick Heroku Application

Name Your Server

The last step allows you to name your server.

Name Your Server

Awaiting First Deploy

Now that our deploy is set up, we’re prompted with a button that will allow us to deploy immediately. We’re also told that the next successful build of master will trigger this deployment.

Awaiting First Deploy

Deploying After Build Passes

Here we can see our next commit triggering a deployment after the CI build succeeded:

Deploying After Build Passes

Deploy In Progress

We can click the deployment that got started and see that it’s in progress. Here it’s actually queued up to start:

Deploy In Progress

Deploy Success

Finally, we can see that our automated deployment to Heroku was successful and our latest commit is now live on the site!

Deploy Success

Summary

So with that we went from an application that we had manually deployed to Heroku, to a rock solid CI + CD setup that we can use from now on. Semaphore made it very simple to set up, so someone without any experience with Continuous Integration or Continuous Deployment can just click through very straightforward wizards and get the same setup that I historically had to run fairly heavy infrastructure to support. On one hand, that seems so unfair! On the other hand, it means that we can avoid running this sort of infrastructure on our own for a lot of projects going forward. I hope you enjoyed it!

Bio

I’m Josh Adams, CTO of Isotope11 and the voice and keyboard behind ElixirSips. ElixirSips is a screencast series that can take you from Elixir newbie to experienced practitioner, as it walks through my entire experience with Elixir from my first bit of code through to building production applications. It contains over 22 hours of videos covering a wide variety of projects. If you’re interested in learning Elixir, give it a shot - I think it’s great! :)

Introducing Easy Continuous Deployment to AWS Elastic Beanstalk

Amazon Web Services (AWS) is a global leader in cloud computing services. It comprises dozens of services and the default approach, of course, is to learn how to optimally use, provision and monitor each one that best fits your application’s needs.

Continuous deployment from GitHub via Semaphore CI to AWS Elastic Beanstalk

But what if you would rather use AWS as a platform and not worry about what’s happenning in the lower layers, such as EC2 or Elastic Load Balancing? In that case something like git push aws would be great.

That’s what AWS Elastic Beanstalk is for. With Elastic Beanstalk, you can quickly deploy and manage applications in the AWS cloud without worrying about the infrastructure that runs those applications.

Without much knowledge about the AWS and Elastic Beanstalk platform, the road from working source code to a continuously deployed application that’s running in production can still be a bit bumpy. So today we’re happy to announce an integration that lets you easily set up continuous deployment from Semaphore to AWS Elastic Beanstalk. Check out the brief screencast that shows the quick setup process below.

Our goal has been to simplify the process as much as possible. For this reason, Semaphore can detect your currently available Elastic Beanstalk applications and guide you through the rest of the process with little input required.

You can tell Semaphore to automatically deploy your application from a selected branch whenever all tests pass, but you can also choose to do it manually yourself. At any time, your team will have a shared deployment history and an easy and uniform way to deliver new versions of your applications.

To help you get started from scratch, we have also published a detailed tutorial. It uses a Ruby application as an example but the same process applies to any programming language:

We hope that this integration will help you in your continuous integration workflow. Happy building!

Platform Update on October 20th

The upcoming platform update is scheduled for October 20th, 2015.

Cassandra is now on version 2.2.2.

Git has been updated to version 2.6.1.

Go gets an update with version 1.4.3, which includes security fixes for the net/http package and other bugfixes.

io.js gets an update with version 3.3.1.

MySQL has been updated to version 5.6.27, including a lot of InnoDB and Replication bugfixes.

NodeJS gets one version update with 4.1.2. To use this version in the release candidate platform, add nvm use 4.1.2 to your build commands.

PHP receives two updates with versions 5.5.30 and 5.6.14.

RethinkDB gets an update with version 2.1.5.

Trying the new platform

You can evaluate the new platform right away by selecting Ubuntu 14.04 LTS v1510 (release candidate) from the Platform section of Project Settings. We encourage you to try it out, so that we can fix the issues you may encounter until the final release on the next Tuesday.

Changes in the final release

Cassandra is now on version 2.2.3.

Git has been updated to version 2.6.2.

NodeJS 4.2.1 LTS has been added to the platform.

Redis gets and update with version 3.0.5.

Qt WebKit gets an update with version 5.4.2, including important security fixes. This version maintains backwards compatibility with Qt 5.4.1. Keep in mind that switching between Qt versions requires expiring your project’s cache.

A full list of changes is available in the platform changelog.

Build Commands Editor 2.0

Here at Rendered Text, we’re always thinking about ease of use. And with continuous integration, that ease — or pain — shows itself at the very beginning: the moment you start setting up your project. While Semaphore tries to infer or recommend you the right build commands, many projects need to customize their build commands sooner or later.

The build commands editor has remained mostly unchanged since we’ve launched parallel CI execution back in 2012, which let you speed up your test suite by splitting it in parallel build threads.

The editor definitely has some limitations. For example, adding a new command to a project that is utilizing multiple parallel threads, aside from keyboard input, has required about five mouse clicks.

We’ve been thinking deeply about how we can make this process faster and easier. So today we’re happy to announce availability of a completely new version of CI build commands editor on Semaphore.

Watch a quick screencast below for a taste.

As you can see, we’ve unbundled what was previously one list of commands into distinct sections:

  • Any commands that you would want to run in each parallel thread go into the (optional) Setup thread.
  • You can add a new parallel thread by actually clicking to add a new parallel thread, instead of adding a command and “scheduling” it into a desired thread number.
  • Same goes for commands you would like to run after each thread — the Post-thread commands, as we call them.

Threads are clearly separated, and you can even give them a name which would later be used on the build page. As a reminder, parallel threads on Semaphore run in different and completely isolated environments. Of course, if your project doesn’t require more than a single thread, none of this is required and the screen remains simple.

There are more handy details that are enabled by this new design:

  • You can drag and drop commands between threads.
  • Want to quickly edit a single command? Just click on it, edit and press Return.
  • If you are editing all thread commands at once, press Command-Return if you are on a Mac to save them quickly.

We hope that you’ll enjoy using the new build commands editor the next time your add or customize a continuous integration project on Semaphore. If you have any feedback or notice any bugs, please let us know.

Happy building!

Platform update on September 22nd

The upcoming platform update is scheduled for September 22nd, 2015.

Cassandra has been updated to version 2.2.1.

Chromedriver gets an update with version 2.19, which supports Chrome versions v43-47.

Git has been updated to version 2.5.2.

PHP receives several updates with versions 5.4.45, 5.5.29, and 5.6.13.

Redis is now on version 3.0.4.

RethinkDB gets an update with version 2.1.3.

New things

Go 1.5 is now available in the platform. It can be selected by adding change-go-version <version> to your build commands. Valid versions are 1.4 and 1.5. After the release candidate period of the platform, the new Go version will be selectable in Project Settings.

Node.js 4.0.0 is added to the platform, along with io.js 2.5.0 and io.js 3.3.0. These versions can be activated by adding nvm use <version> to your build commands. After the final release of this platform update, the selection will be available in Project Settings too. Before switching to Node.js 4.0.0, please see the list of packages which currently don’t work in combination with this version of Node.js.

Trying the new platform

You can evaluate the new platform right away by selecting Ubuntu 14.04 LTS v1509 (release candidate) in the Platform section of Project Settings. We encourage you to try it out, so that we can fix the issues you may encounter until the final release on the next Tuesday.

A full list of changes is available in the platform changelog.

Get future posts like this one in your inbox.

Follow us on