From the office! is a daily (almost) posting routine that I keep to journal about the tech things I have been doing in my day-to-day office life.
I am Nico,
I am a senior engineer for a ticket broker based in London.
CI Pipelines in Bitbucket
Let's start with the official definition from Bitbucket's documentation:
Bitbucket Pipelines is an integrated CI/CD service built into Bitbucket. It allows you to automatically build, test, and even deploy your code based on a configuration file in your repository.
What that means in simple English is that a pipeline allows you to write commands, that can perform various automatic tasks, on your repository.
Nowadays, this is a significant concept because with the dawn of DevOps ideally, we are able to deploy more often and as fast as possible.
That's why we have concepts such as continuous integration, continuous delivery, and continuous deployment.
What is Continuous Delivery?
Continuous Delivery means being able to change code and configurations quickly and most important safely.
As uncle Bob loves to say "software must be soft".
The word soft means easily changeable.
As a developer, you will quickly learn that it is better to have a piece of code that doesn't currently work but is easily modifiable, thus fixable, than a perfectly working one that you are scared to touch because you can break things.
That's why polymorphisms, inheritance or testing are such important concepts
How to implement the pipeline
The way the Bitbucket pipeline is implemented into your repository is very easy.
It is just a YAML file with some configurations on it.
This file has to be at the root of your project and must be called bitbucket-pipelines.yml.
Of course, as prerequisites, you must have a Bitbucket account and a repository to work with.
A pipeline is made up of a list of steps, and you can define multiple pipelines in the configuration file.
The pipeline configuration file can have multiple sections identified by particular keywords.
A single pipeline can have up to 100 steps which is plenty.
It all starts by defining the sections,
Here are the ones I find the most useful:
default
The steps inside the default keyword contain work for all branches that don't match a pipeline definition in other sections.
The default pipeline runs on every push to the repository unless a branch-specific pipeline is defined.
branches
Defines a section for all branch-specific build pipelines.
Easy!
pull requests
A special pipeline that only runs on pull requests initiated from within your repository.
Example of the code:
image: php:8
pipelines:
default:
- step:
script:
- apt-get update && apt-get install -y unzip
- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer install
- vendor/bin/phpunit
A more complex one
pipelines:
branches:
develop:
- step:
name: Build docker image
caches:
- composer
script:
- apt-get update && apt-get install -y unzip
- docker-php-ext-install mysqli pdo_mysql json sockets
- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer install
- parallel:
- step:
caches:
- composer
name: Unit tests
script:
- vendor/bin/phpunit
- step:
caches:
- composer
name: Code sniffer
script:
- composer phpcs:all
- step:
name: Deploy to preprod
script:
- echo "Deployment"
Conclusion
I am Nico,
I have been a web developer for almost a decade now.
Been working with world-class businesses and award-winning marketing agencies situated in the heart of London.
Also, I write articles and tutorials on my blog and online communities and help businesses build their presence online.
Top comments (0)