Bitbucket pipelines are the native Continuous Integration (CI) part of the Bitbucket GIT repository service. If you are already using Bitbucket for your source control needs, you might think that adopting Bitbucket pipelines is also natural as they are tightly integrated.
Choosing Bitbucket pipelines just because they are already part of the bitbucket service might seem a good idea at first glance, but in reality, it forces you to use what is readily available instead of what is truly appropriate to your needs.
Bitbucket is one of the supported providers in Codefresh (like GitHub and GitLab) so it is perfectly possible to still use Bitbucket as a source code repository and delegate all pipelines to Codefresh.
In this post, we will see a comparison between Bitbucket pipelines and Codefresh. The reality is that like all other traditional solutions, Bitbucket was originally a pure CI solution which was later retrofitted with deployment capabilities. Codefresh, on the other hand, was designed from scratch with the full CI/CD lifecycle in mind.
Table of contents:
- Bitbucket pipelines only work with Bitbucket, Codefresh works with Bitbucket, GitHub, and GitLab
- Bitbucket pipelines are limited to 10 steps
- Bitbucket pipelines are not designed for microservices
- Bitbucket pipelines git triggers are very limited compared to Codefresh
- Build caching must be manually configured in Bitbucket pipelines
- Docker support is not first class in Bitbucket pipelines
- There is no Docker cache in Bitbucket pipelines
- Codefresh has explicit support for Kubernetes deployments
- Codefresh has explicit support for Helm deployments
- Bitbucket pipelines are SAAS only
Let’s see all these points in order…
Bitbucket pipelines only work with Bitbucket, Codefresh works with Bitbucket, GitHub, and GitLab
This is probably the first important point regarding this comparison: Bitbucket pipelines only work with Bitbucket repositories. If your organization works purely with Bitbucket this might not be a problem. But in more realistic situations (with big companies) it is very common to work with multiple source code providers.
Bitbucket pipelines only work with the integrated Bitbucket repositories and the only way to work with another repository is by importing it first as a native source code repository (essentially creating a second copy of it). This means that if you want to collaborate with people that have repositories in GitLab, GitHub or any other external source, you will be forced to maintain a completely separate repository just for taking advantage of Bitbucket pipelines (a very impractical solution).
Codefresh is agnostic as far as the source code is concerned. You can connect any type of git repository from GitHub, GitLab or Bitbucket (or even your on-premise git platform) and use all of them in the same manner. You can even mix source code from different git providers in the same Codefresh pipeline.
In summary, if you have code repositories outside Bitbucket or want to collaborate with people that are not using Bitbucket, Codefresh is only viable CI/CD platform.
Bitbucket pipelines are limited to 10 steps
This is a second Bitbucket limitation that may prove a deal-breaker for big organizations. Bitbucket pipelines can only have a maximum number of 10 steps and even if you use parallel steps this number is still a limit on the total number of steps used.
You may never hit the limit if you work on small pipelines. Any large organization, however, will most likely need pipelines with more steps, especially when it comes to building microservices that consist of multiple applications.
Codefresh has no limit on the pipeline steps (as long as runtime resources are available) so you are free to create and design any pipeline structure you want.
In Bitbucket the pipeline shown above would not be possible as it contains 15 steps.
Bitbucket pipelines are not designed for microservices
Bitbucket pipelines are mainly a CI platform that existed long before containers and microservices gained popularity. As such, it was retrofitted with container support, while still keeping the legacy design that was present before.
This is more evident in how thing are organized in Bitbucket pipelines. Everything is attached to a single project. This made sense in the era of monolithic applications but is totally inflexible for microservices.
As a quick example, the build view in Bitbucket pipelines always shows the builds for a single project:
If you have multiple projects that form an application, it is impossible to see all of them together in Bitbucket pipelines.
Codefresh on the other hand is designed with micro-services in mind and integrations and view are at the account level instead of the project level. In the same example, Codefresh allows you to view builds from multiple projects at the same time.
The same mentality of a single monolithic application is evident in all other aspects of Bitbucket pipelines. Even pipelines themselves are attached to a single project. Codefresh is a much more flexible solution that allows you to create pipelines attached to multiple git repositories (or even none).
Bitbucket pipelines git triggers are very limited compared to Codefresh
Building a basic pipeline that only checks out the code at each commit is very easy to do in Bitbucket. Unfortunately, this is the only way git triggers can be used. The only choice you have is whether you will build a commit, a tag or branch.
Codefresh has a much more advanced triggering system that can be used with multiple conditions:
For example, you can define a trigger only when a Pull request is created against a specific branch. With Codefresh you also have full monorepo support where a trigger will only happen if specific files within the repository change. Bitbucket pipeline have no such support out of the box.
Build caching must be manually configured in Bitbucket pipelines
In Bibucket pipelines (like GitLabCI) you have to setup manually caching for your pipelines. Bitbucket will not cache anything out of the box and it is your responsibility to define which directories will be cached.
To enable cache, you need a special directive in your Bitbucket pipeline definition to select which programming language you want to use. Here is an example for Node:
pipelines:
default:
- step:
caches:
- node
script:
- npm install
- npm test
The same is also true for build artifacts. There is a separate syntax in Bitbucket pipelines where you define you artifacts.
Codefresh has instead fully automatic caching. If you want to move a folder from one step of the pipeline to the next (that either contains dependencies or artifact) you need to do exactly… nothing!
Codefresh accomplishes this by automatically mounting a shared volume between all the pipeline steps. The project folder itself is checked out on this volume.
In the example above the node_modules folder is automatically shared with all the steps in the pipeline. You don’t need to define it as a special cache folder.
Notice that this shared volume is also cached by Codefresh between subsequent builds of the same pipeline. This makes Codefresh builds very fast without any extra configuration.
Docker support is not first class in Bitbucket pipelines
Like several other legacy CI solutions, Bitbucket pipelines was originally a VM based platform. When Docker appeared into the scene, Bitbucket pipelines added support of running Docker commands manually. Here is an example Bitbucket pipeline:
pipelines:
default:
- step:
services:
- docker
script:
# build the Docker image (this will use the Dockerfile in the root of the repo)
- docker build -t $IMAGE_NAME .
# authenticate with the Docker Hub registry
- docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD
# push the new Docker image to the Docker registry
- docker push $IMAGE_NAME
The commands just represent what you would run locally in your workstation. You also need to litter your pipeline with Docker credentials. In summary, with Bitbucket pipelines “Docker support” just means the ability to run Docker commands.
Codefresh was designed with containers in mind and it has proper Docker support by including the following:
- A free private Docker registry built into the platform
- Special Docker pipeline steps for creating and pushing images
- Automatic pushing to the internal Docker registry
- Account-level external Docker registry integration.
Codefresh has a built-in registry (comes for free with all accounts) as well as handy UI dashboard that allows you to inspect your Docker images.
Apart from the internal Docker registry, you can also link any external Docker registry (and promote images between registries). The Docker credentials are defined once in the account level and all your pipelines are just using the integration.
All Codefresh pipelines automatically push their artifacts to the internal Docker registry. If you want to push to external registries as well you can easily use the dedicated push step.
Here is a Codefresh pipeline:
build_image:
title: Building DockerImage
type: build
image_name: my-app:master
push_name:
type: push
title: Pushing to ECR
candidate: ${{build_image}}
tag: latest
image_name: codefresh/my-app
registry: my-ecr-registry
Notice the lack of Docker login instructions or credentials.
In summary, Codefresh offers everything you need to work with Docker images (including a private Docker registry), while with Bitbucket pipelines you need to setup everything by yourself with custom scripts.
There is no Docker cache in Bitbucket pipelines
We have already seen the fact that Codefresh also includes a private Docker registry (and associated dashboard). Codefresh takes Docker support one step further by having full Docker cache for all build nodes resulting in very fast builds.
The Docker cache in Codefresh works exactly like the local Docker layer cache that you are familiar with and can help you achieve very fast builds as only the changed layers will be fetched for each build.
In the pipeline above, you can see that Codefresh automatically detects which layers have already been built.
Bitbucket pipelines on the other hand have zero support for Docker cache. Thus, everytime that you build a container you pay the full price for the build even if only some layers are actually changed.
Here I am running a Bitbucket pipeline a second time (without actually changing in my Dockerfile) and you can see that all Docker layers are downloaded again and again.
Depending on your Docker migration path, not having Docker cache in your pipelines might become a serious blocker in the way developers interact with the CI/CD platform.
Codefresh has explicit support for Kubernetes deployments
Codefresh is currently the only CI/CD solution that offers an integrated Kubernetes dashboard.
Once you connect your cluster you can see in real time all the services, pods, and deployments from your releases.
Bitbucket offers nothing for verifying deployments. Once a deployment is finished you need to use an external service to actually see it running.
Codefresh has explicit support for Helm deployments
Similar to Kubernetes, Codefresh comes also with full support for Helm. Out of the box, you get:
- A private Helm repository for your releases
- The ability to connect any external Helm repository
- A Helm release dashboard
- A Helm deployment dashboard
- A Helm environment dashboard.
Here is the Helm dashboard:
Here is the list of all Helm releases (public and private repos are supported):
And here is the Helm environment board:
In summary, the Helm support in Codefresh is very comprehensive. There is zero support for Helm releases in Bitbucket pipelines.
Codefresh also offers on-premise and hybrid installation modes
Bitbucket Pipelines are only offered as a SAAS product. This is fine if your application and source code is already on the cloud. There are several companies however with strict security requirements for keeping source code on premise (e.g. financial or medical).
Codefresh also offers an on-premise installation mode for companies who wish to run the Codefresh platform on their own infrastructure. There is also a hybrid mode available so that the builders themselves are running in the customer infrastructure while the UI is still in the SAAS product.
In summary, Codefresh can cater to any type and size of company, while Bitbucket pipelines offer only a single usage mode (cloud version).
Conclusion
Bitbucket pipelines is a CI solution limited only to Bitbucket and small pipelines (10 steps maximum) which was later retrofitted for Docker support as a way to run Docker commands.
Codefresh is a full CI/CD solution with Docker caching, private Docker and Helm registry, Kubernetes and Helm release dashboards.
If you prefer a matrix-style comparison, read the table below:
| Feature | Bitbucket pipelines | Codefresh |
|---|---|---|
| Git Repository dashboard | No | Yes |
| Git support | Bitbucket | GitHub, GitLab, Bitbucket |
| Quay/ACR/JFrog/Dockerhub triggers | No | Yes |
| GIT triggers | Commits only | Any git event |
| Native Monorepo support | No | Yes |
| Global pipeline view | No | Yes |
| Max pipeline steps | 10 | Limited to resources only |
| Built-in dynamic test environments | No | Yes |
| Local builds | No | Yes |
| First class docker support | No | Yes |
| Automatic build caching | No | Yes |
| Docker layer caching | No | Yes |
| Internal Docker registry | No | Yes |
| Docker Registry dashboard | No | Yes |
| Native Kubernetes deployment | No | Yes |
| Kubernetes Release Dashboard | No | Yes |
| Integrated Helm repository | No | Yes |
| Helm deployment dashboard | No | Yes |
| Helm release dashboard | No | Yes |
| Helm environment dashboard | No | Yes |
| Installation | Cloud | Cloud/On-prem/Hybrid |
New to Codefresh? Create Your Free Account Today!
