There are still many development teams out there that are taking their first tentative steps towards Docker, planning to make a move, or that have adopted Docker, but not in production.In the spirit of Dockers 4th birthday (Happy birthday!) we wanted to share why we made a move to become one of the first Docker native CI/CD platforms.
Why did we do it?
Back in 2012 Wercker was on LXC and had a problem. From the moment we started, we were inundated with requests by developers to create specific stacks (programming languages, databases and other services) and include everyone's favorite tools, frameworks and practices into the platform. This task was huge, and we realised at that point that the value of Wercker is not the format, but what you can do with it -- think Mp3 players, it's not the format that changed the way we listen to music, but the portability and accessibility (among other factors) that allows music to act as a soundtrack to our lives, kill the pain of a commute, noisy office or morning jog. The music and services such as Spotify and iTunes are what's impactful, not the Mp3 format.
At Wercker it has always been our mission to make developers’ lives easier, and we've strived to empower developers and not get in their way. With that core principle in mind, we started looking for solutions to our problem. We though we found it when we decided to open up the platform in such a way so that developers could publish their stacks in the form of LXC containers and their steps so that they could customize their automation pipelines. We called it The Open Delivery Platform. With Open Delivery, developers could explore custom stacks (their own as well as others) and steps in the Wercker registry, where they could submit and share custom created boxes, pipelines and steps.
It was here that we created our notion of pipelines (a set of steps and phases aimed at delivering your applications) and realised that the verbs "Build" and "Deploy" are insufficient (which eventually led us to workflows). But still, we felt that something was missing. Finally, Docker burst onto the scene with all its API and tooling, and we felt that we had more (but not all) of the ingredients we needed to help developers achieve their goals. With that, we took one giant leap towards Docker and started to re-platform Wercker.
At the time it seemed like a big gamble, but it paid off, LXC was not the right technology for us or the developers that use us, and we're proud to say that since that first leap we made more excellent re-platforming choices in the form of CoreOs, Fleet and most recently Kubernetes. We're confident that we will continue to make leaps and bounds in our stack by always reminding ourselves of our core principle, which is to make developers lives easier.
So for all those development teams out there making that move, planning to or just starting out and who share a similar core principle, here are some posts we've written about fully utilizing or moving towards using Microservices & Docker and are automating deployments, specifically to schedulers like Kubernetes, running on good IaaS providers.
General thoughts and best practice
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!