Building a Docker-Native CI Service with Codeship Pro

UPDATE: With January 1st, 2017 we rebranded our hosted CI Platform for Docker from “Jet” to what is now known as “Codeship Pro”. Please be aware that the name “Jet” is only being used four our local development CLI tool. The Jet CLI is used to locally debug and test builds for Codeship Pro, as well as to assist with several important tasks like encrypting secure credentials.

Docker has proven to be a productivity boon for software developers and development teams -- big and small. More and more developers and teams are now either fully Dockerized or wanting to get there.

As big fans of Docker and everything it does for software development, we decided to build a truly Docker-native CI/CD service. So we set out to build a product that treats Docker containers and Docker architectures as a cornerstone for a truly modern and native integration, testing, and deployment workflow. That’s why we built Jet.

Jet Is Built For Docker

When looking at Docker usage and talking to Docker users, a few things always jump out as primary reasons for adopting a Docker-based workflow:

• Portability

• Parity

• Developer productivity

When we set out to build a continuous integration/continuous development service that worked with Docker, we wanted to make sure to complement each of those benefits. We figured if Codeship could reuse your Docker setup, require as little proprietary work and time away from your code as possible, as well as take advantage of all the best-practice and microservice workflows that Docker encourages, then we could make CI/CD part of a great Docker application rather than an additional layer that needs to be bolted on to guarantee reliability.

With that in mind, Jet was built with three core ideas to highlight each of those Docker benefits:

• Repository-driven development

• Docker-native CI/CD

• The Codeship Jet CLI tool

Repository-Driven Development

Repository-driven means your developers never have to look anywhere except the code and the repo to test and release software. This is super efficient, allowing teams to stay focused on their code and their projects rather than maintaining CI/CD infrastructure.

We accomplish this by powering everything with two simple .yml files that live in your repo:

• codeship-services.yml

• codeship-steps.yml

The services file defines your Docker application structure, what images to build and download, and how they connect. It’s a mirror of Docker Compose and, in fact, you can even use a Docker Compose file in most cases.

The steps file is a list of commands that gets passed to your containers defined by the services file that we run in the CI/CD process. That’s it! Tests, scripts, artifacting, compiling, pushing images, and deployment -- as long as it runs in your containers, it runs on Codeship just fine.

Because these two files live in your repo, making changes is as simple as a commit. And if anything isn’t working, your developers can work directly with the same code and the same repo to solve the problem.

Docker-Native CI/CD

As we mentioned above, your codeship-services.yml file is a mirror of a Docker Compose file. This is one of the ways we tried to help keep portability and parity intact. There’s no proprietary setup required for Docker application with Codeship. Because we use Compose, you can use your app exactly the way you’ve already built it.

This gets really cool when you couple it with the fact that we actually automatically build and run your containers. Everything that happens in CI/CD is actually happening in your containers:

• You can start to create separate services for testing, compiling, and deploying your application (check out this example).

• You can push images from one service that form the basis of the next service in your pipeline.

• You can deploy your containers, artifact your code, or both. Deploy however you want, wherever you want. If you want to learn more about that, download our free ebook, An Introduction to Deploying Docker Apps with Codeship Jet.)

When we say Docker-native, we mean that containers run the process. Your Docker images are the way we build and run the CI/CD process, allowing you to think of testing and releasing your code as part of your architecture and avoiding any bolt-on baggage by including the necessary CI/CD functions.

The Codeship Jet CLI tool

Finally, we wanted to make it easier and faster to validate and improve your code as well as your CI/CD process. So, we built a Jet command line tool that you can install locally. This keeps developers as productive as possible by creating the shortest possible cycles of feedback and iteration.

Made a change to your services or steps file or want to know if your tests are going to pass? You can run jet steps from your terminal before even committing your code, and Jet will run the entire process defined in your steps file locally. If there’s an error or a big exception, you’ll see it without having to push up a commit, trigger a build, and wait. This lets your team solve problems and move on as fast as possible.

Conclusion

Ultimately, you want CI/CD because you want to release code that works as quickly as possible. You want your team to be as productive as they can be with as few distractions as possible. Docker goes a long way in helping with this, and we built Jet to fill in the gaps. Everything Docker does, we extend into testing and releasing your software.

You can test and debug locally, reuse your Docker application’s Compose-based architecture to test, run, and deploy Docker-native architectures and fix all problems without having to ever leave you code editor and your repository.

Are you interested in seeing Jet in action? Check out my short demo. Want to try it with your projects? Request a free 14-day trial right here and learn more in our Codeship Getting Started Documentation articles.