Bitbucket Pipelines now supports building Docker images, and service containers for database testing

Try Bitbucket Pipelines

Companies love delivering their applications using Docker. According to Forrester, 30% of enterprise developers are actively exploring containers, and Docker is the dominant DevOps tool, with 35% of organizations adopting it, according to a recent RightScale survey. Docker provides a painless method of building and deploying applications as a set of independent microservices, which are scalable and resilient.

We developed Pipelines to allow all teams to test and deploy their software faster, using Docker containers to manage their build environment. Teams save countless hours and headaches by avoiding manual build server configuration, choosing instead from the enormous range of publicly available containers on Docker Hub, or bringing your own Docker image for a custom build environment.

We’re thrilled to announce support for building Docker images and Service containers in Bitbucket Pipelines. 

Use Bitbucket Pipelines to build, tag and push Docker images

Starting today, you can build your application as Docker containers, benefiting from the portability and minimal overhead of containerization. No need to install an additional plugin or run your own Docker service like in Jenkins or other legacy CI systems – just enable with 2-lines in your bitbucket-pipelines.yml and it just works.

This seamless Docker integration facilitates a whole new set of workflows for Bitbucket teams, including:

• Running automated tests, then building your validated app as a Docker image and pushing it to a container registry
• Building and pushing a Docker image to a registry, then manually triggering a pipeline to deploy it to ECS or Kubernetes
• With service containers (described below), build, tag and push a Docker service in one pipeline, then pick it up as a dependency to test in another.

Bitbucket is now the only tool your team needs to code, build, test and deploy your applications in the cloud, covering the full lifecycle for teams building with microservices.

Service containers in Bitbucket Pipelines enable flexible container-based testing

Setting up integration testing with a database or other dependency on your build server is usually a mess of configuration files. You might even need to configure additional agents or build Amazon AMI images to get the dependencies up and running for your build. Docker has the potential to make that so much easier, with thousands of pre-built images for commonly used software like MySQL and Redis, and standardized configuration through environment variables.

Today we’re excited to announce service containers for Bitbucket Pipelines, bringing the power of Docker to your test environment configuration. You can now run up to three background services in your pipeline, in addition to your build container, using your own Docker images or any of those available on Docker Hub. This makes it a breeze to set up integration testing with databases like MySQL or PostgreSQL or run other common services like ElasticSearch or memcached.

There are several benefits to how service containers work in Pipelines:

• Service containers are started and stopped automatically alongside your pipeline, minimizing the necessary configuration of these services compared to other systems.
• All containers share the same network interface, so there’s no need to map ports between your build and service containers like you might in other environments (e.g. those using docker-compose).
• With Docker Hub hosting many versions of all the popular open source services, testing your software against different versions of dependencies is much easier in Pipelines than in any build system that requires you to provide your own images.

Why switch to Bitbucket Pipelines from your legacy build server?

We talk with many companies who are still using legacy build servers like Jenkins and struggling with three big challenges:

1. Teams spend a lot of time on manual build configuration and managing build agents. This maintenance can be a huge cost to the teams, often including several full time build engineers for larger dev teams.
2. Using a separate build server presents a big speed bump for developers who need to switch contexts frequently between code and build during their day-to-day work.
3. The team doesn’t have full control over deploying their releases, leading to manual release steps that are error-prone, encourage riskier less-frequent releases, and slow down the feedback loop between the team and their users.

With integrated Pipelines for continuous integration and delivery (CI/CD), Bitbucket solves these problems and helps your team move faster. Pipelines sits within your codebase and removes the barrier between the team, the code, and the configuration. The configuration is simple and lives in your code, versioned and managed alongside your application.

With Bitbucket Pipelines, there's no need to switch to another application, no need to juggle permissions and access, or set up build servers – and thanks to our cloud infrastructure you get unlimited concurrent builds.

Haven’t tried Bitbucket Pipelines?

If you haven’t given Bitbucket Pipelines a try, we’ve extended free build minutes for Pipelines so you can try for free. As always, please tell us what you think of this feature by tweeting @Bitbucket Pipelines.

Try Bitbucket Pipelines

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.