Semaphore, our hosted continuous integration service, is being continuously improved. Here are the highlights of what’s new since our last post.
Build environment improvements
We’ve upgraded our build environment, making PhantomJS, Java, Sphinx and Memcache, among others, available out of the box.
There’s a more complete list on our documentation site, and we know quite a few people who will benefit from PostgreSQL 9.1 and Firefox 13.
If you’re using MySQL or PostgreSQL, Semaphore now also exports some environment variables that make the database name, user and password available. You may use them if your build requires some custom scripting.
A better Solo plan
We’ve changed how our Solo plan works - from $9 with no collaborators to $14 and unlimited collaborators. While we’ve thought hard about pricing before we’ve announced it, it’s a learning process. Our goal for the future is to make pricing changes that will give our users even more bang for the buck.
Invite collaborators after adding a project
Semaphore knows about your collaborators from GitHub automatically. You can invite them while you’re adding your project, and when they sign up it is waiting for them on their dashboard.
Now we’re introducing a feature that lets you invite them from project settings as well:
This will be useful if you decide not to invite them while you’re adding a project to Semaphore.
As a project owner you can now set up Hipchat post-build notifications. The procedure is very similar to how Campfire works and what you’re used to if you’re a Hipchat user.
The road ahead
Beginning of an API, JRuby and post-build webhooks are just around the corner, as we move on to a live build log and even bigger things in our mission to make continuous integration a compelling experience for all developers. Watch this space or follow @semaphoreci for further updates.
Hot on the heels of Semaphore’s public launch, we’ve shipped two important and frequently requested features so far: Campfire notifications and support for different versions of Ruby.
We’re big fans of Campfire and use it both for our internal communication and on some client projects when it makes sense. As we’ve heard from our users, this process is fairly common, and we’ve made it as easy to have build notifications come from Semaphore to your Campfire room as you’re used to on other web services. Go to your project settings, open the “Campfire” tab and fill in the blanks:
After that you will receive messages such as this one:
The message includes project, branch name, author of the last commit and its’ message. The behaviour is the same as with emails - first build of a branch is always sent, after that messages are sent only if there’s a change in build status.
As we’ve explained in previous post, limiting ourselves to support only Ruby 1.9.2 was just a matter of cutting down the MVP. However, we’re aware that many people now work with 1.9.3 or are still on 1.8.7, and we’re very happy that we can announce support for these versions so quickly:
Feel free to let us know how this works for you. Happy building!
A couple of months ago in a blog post Introducing Semaphore we explained what drove us to start working on Semaphore. For those of you who don’t know, Semaphore is hosted continuos integration service for Ruby applications. Now we are launching it as a complete, but ever-evolving product and I want to talk a bit about what happened in between.
Evolving the MVP
Close to two hundred people signed up to beta test Semaphore. We invited a better part (sorry if we haven’t invited you early), and those who were invited actually became a part of our team in a way. Beta testers contributed immensely to what is Semaphore right now. From some tips like minor UI improvements to brainstorming about pricing. Thank you so much people and I hope you enjoyed it as much as we did.
When the beta period started we had just one build server and were supporting just Rails projects with MySQL and PostgeSQL. We of course knew that it was an extremely limited subset of all technologies on the market. But we wanted to simulate BDD also in company and product development. So we intentionally built and supported less and added more only when we felt a strong need for an additional feature.
Although that initially led to a high number of feature requests, it also enabled us to launch the product in reasonable time and with limited resources while keeping most of our beta testers, now customers, happy.
When saying happy, I really mean that they are happy-happy. We of course believed that there are people who will like seamless GitHub integration and polished interface, but we never expected frequent emails where people will actually say “Thank you for building such a great service”. I don’t know, maybe it’s really true that developers are that nice; I haven’t worked on a product for developers before.
A bit into details
“Only Rails” was way too rigid. We now support any Ruby project.
Connected with only Rails idea, we didn’t have custom build commands. This is definitely something that is needed for CI. We were probably blinded a bit in this area by how little configuration is possible on Heroku to work great. But it’s not like all people use Rails and Heroku all the time, there are many custom stand alone applications.
Only MySQL and PostgreSQL. Although you might think this was a huge limitation, it was totally the opposite. Seems like the NoSQL hype is over and that relational databases still work for most of the projects. Situation with databases on Semaphore now is pretty much - you name it, we have it. But it was a good call that we didn’t worry too much about them in the beginning.
Only 1.9.2. Just fine! And yes 1.9.3 is available on request, but will be available through a select box very very soon.
Adding and removing branches was manual at first and now it’s automatic through GitHub web hooks and people love it.
One fast machine with on-demand virtualization and no algorithm for supporting N machines. Right call. Once we understood bottlenecks of hardware we addressed the problem and Semaphore is now successfully running on a couple of high-performance build servers.
Pricing! This one was really tough. It’s still early to say if we got it right. Overall people are OK with it. For this one you can think and brainstorm with your team as much as you would like but you will not move forward until you talk with your potential customers. We probably read that advice here and there a couple of times but didn’t really understand it until we really faced it.
If you read this far, check it out at https://semaphoreci.com, our customers say it’s a good CI solution and we would like to hear you opinion.
Since we launched Semaphore as private beta a month ago we have received a lot of positive feedback along with many feature requests. We saw various projects, and realized that many people need to do something in the test suite that we cannot guess. Or simply want to build a Ruby project that is not a Rails app.
Today we are introducing project analysis with custom build commands. Analysis is a step that Semaphore performs on every new project. During analysis it tries to learn as much as possible about your project and the output is a set of build commands that match your application. Build commands can be reviewed and changed before the build process begins in case Semaphore misses something specific to your application.
Typical use cases for custom build commands that we have seen so far are:
setting up custom database configuration files
calling a custom rake task for setting up seed db data
passing special flags to default rake <test_framework> tasks
exporting environment variables that contain sensitive information which you don’t want to keep in your repository
An important side-effect of this is that Semaphore can now build any Ruby project!
We’re currently letting the next wave of beta testers in, so if you haven’t applied already, shoot us an email to email@example.com
Semaphore is a product of scratching our own itch. Rendered Text as a team of five people usually works on a few projects at a time. Although most of our projects are long term relationships, we take smaller projects that last two to three months. By bootstrapping applications over and over again we detected a pattern.
Initial spec is defined with client. Git repository is created and our template application is imported and pushed to GitHub. Staging app is created on Heroku. Both GitHub and Heroku are services that take burden off developers’ back and put a smile on their face. But same cannot be said when it comes to third step in the process of bootstrapping a new project and that’s the infamous continuous integration server.
Setting up and maintaining a CI server with Jenkins or any other CI software is a pain and takes time, easily a day, even if you are developer with devops experience under your belt. Let me mention just a few things that you will have to worry about during CI server setup: SSH keys, hooks, iptables, SSL and user management. Even if you haven’t gone through the process of setting up CI you can imagine that it’s a tiresome process that you as a developer shouldn’t have to worry about. You should focus on your application!
Looking from a perspective of a person who is running a small consulting agency, you know that every day counts and you don’t want to lose a day so easily on a project that already has a limited budget. And from a perspective of a developer, you know how much you love GitHub and Heroku for taking care of their part of the job and you just cannot be looking forward to setting up and maintaining CI server.
With Semaphore we addressed all of these issues and made the process of setting up continuous integration super easy. You just have to create a Semaphore account, authorize it with GitHub, select a project that you want to build and you are done! Checkout a short screencast that we prepared and sign up to see it for yourself.