Elevating DevOps with a Tight Bitbucket to Jenkins Integration
At Mohami, we don’t typically do things like this — we don’t take on the responsibility of maintaining and enhancing another developer’s code. For one thing, we already maintain a sizeable and successful portfolio of plugins in the Atlassian marketplace.
But Webhook to Jenkins for Bitbucket (WJB) isn’t a typical plugin. WJB fills gaps in DevOps automation for teams that use Bitbucket for source control and Jenkins for scripted automation of Continuous Integration (CI).
This is about elevating DevOps — how you can automate the time-intensive aspects of the build-test-deploy process, and use Continuous Integration to pull back more time for your developers to actually write code.
We’ll start with what WJB does, talk a little bit about its rebirth and its strange history, then take a deeper dive into features, and how you can try WJB for free.
What is WJB?
WJB is a Bitbucket plugin that automatically triggers Jenkins scripts when developers commit, pull or merge code in Bitbucket. That eliminates single points of failure that previously relied on manual intervention and something you can’t always count on — that your team members will reliably follow the rules. It lets you trigger specific pipelines in Jenkins based on source control activity, project and other criteria. It glues the interaction with source control together with the CI process, raising the bar for DevOps automation.
With over 5000 integrations in the Atlassian ecosphere, the WJB macro has already played an important role in DevOps for many software teams, but it in 2017 was not well-maintained and in danger of becoming a cautionary tale.
Back then, it was for those reasons that we decided to acquire the WJB code base. Mohami management and engineering alike recognized its undeniable value for developers practising CI, and we were excited to take it on.
The Brief Strange History of WJB
You would think a development tool with such undeniable value to CI would find the support and maintenance it needs to thrive, just organically. Afterall, it provides an important bridge between two of the most popular development tools in Bitbucket and Jenkins.
The value behind it was undeniable. But as we began the process of onboarding the macro and conducting due diligence on the source code, the active open issues, and the installed base, the details of the situation came into focus — enhancements were taking months to complete, bugs persisted and were not addressed, and it wasn’t keeping up with the Bitbucket release schedule.
And to be fair, none of this was anyone’s fault — it was simply an artefact of the previous developers’ circumstance. They gave it as much attention as they could but other priorities were pressing, and WJB was slipping.
That was the situation. In short, there was a ton of technical debt that had to be addressed, and while it had to become a revenue stream for us to make this work, it would be expensive to fix, no matter what.
Our team attacked it — we cleaned up the source, fixed the ledger of open bugs, and WJB was reborn.
Since taking it over, we’ve added numerous enhancements, refactored and stabilized the code base, and improved performance.
A Primer on Continuous Integration and Jenkins
If you’re already familiar with Jenkins and Continuous Integration, you can safely skip to the next section on the Feature-Rich Flexibility of WJB.
But if you’re somewhere on the spectrum between learning about, exploring or considering CI, or even if you’re right on the cusp of implementation for your team, here are some of the basics…
DevOps in 2019 is all about CI, continuous delivery, and continuous deployment. A brief informal survey reveals a surprising number of teams that could benefit from CI are stuck in very unautomated environments.
It’s worth a little introspection about your internal methodologies. Are you still waiting for nightly builds to pull and test code? Do your developers still run test scripts manually?
Many teams still run under antiquated process frameworks like this.
Continuous Integration is equal parts process, tools, and culture. It keeps the list of open bugs under control, helps maintain a stable code base, and when properly automated, can greatly improve developer productivity. While tools like Jenkins automate the build, test, and deploy process, the effectiveness of CI also depends on developers committing their code frequently — often several times a day. While the developers remain productive, CI platforms like Jenkins build the release, run the tests, and deploy to other platforms. When the build breaks, the tools automatically notify the team.
As a CI platform, Jenkins is easy to use, highly flexible, and distributed. Its plugin architecture makes it extensible, and even if you don’t want to create plugins yourself, thousands are available online. You can commit code directly to Jenkins of course, but users of Bitbucket may prefer to maintain source on that platform while leveraging Jenkins for what it does best — orchestrating the build-test-release-deploy process.
Before it was acquired by Oracle, Jenkins was known as ‘Hudson’, a side-project of an engineer at Sun Microsystems. But Jenkins has been in use since 2010, and adoption hasn’t slowed since.
Feature-Rich Flexibility
At its core, the WJB macro is a highly configurable and flexible hook that notifies Jenkins about your Bitbucket commits, pull requests and merges. It easily ties builds, deployments and automations to your Bitbucket Server workflows.
A straightforward UI makes WJB easy to configure your hook on a project or repository level, and test your configuration and connectivity with a single click. You can add multiple Jenkins servers, trigger builds manually, whitelist/blacklist branches, ignore commits from specific users, and much more!
From a single commit, WJB can notify multiple Jenkins servers, and it allows you to configure triggers uniquely on a per-project basis.
Features
● Support for project level configuration.
● Support for adding multiple Jenkins servers.
● Support for build parameters.
● Easily test your configuration on the hook settings screen.
● Ability to retrigger builds manually from the pull request screen.
● Highly configurable, with options to ignore certain committers, branches and more.
● Support for Bitbucket Mirrors.
● Promotes SNI for hosts.
Fire and Forget Trigger Rules
WJB supports four major source control events to trigger a notification to Jenkins:
Pull Request Opened Is fired whenever a pull request is opened.
Pull Request ReOpened Is fired whenever a declined pull request is re-opened again.
Pull Request Merged Is fired after a pull request is merged
Repository Refs Changed Is fired when any sort of git reference change happens. This includes commits, pushes, edits, branch creations and more. Note, we filter out all reference deleted events.
All of those actions can trigger unique pipelines on a per-project basis and particular team members can be excluded from triggering the notification. You can even use specific tags to determine which specific pipelines to trigger.
Jenkins and Bitbucket are best-of-breed tools, but as with many apps in the toolbox, it’s the integration between them where the real magic happens.
At Mohami, we’ve learned directly from our customers where the integration sweet-spots really are. For example, when you’ve got different automation pipelines for each project, you can target the trigger based on different Bitbucket actions, and trigger unique pipelines based on multiple criteria.
Advanced Configuration and Workflow Options
No two development teams do devops exactly the same way. Any process that relies on manual intervention from the team becomes a weak point in the overall chain of automation — a single point of failure. That’s why extensibility provided by Jenkins is so valuable to development teams, and why criteria-based triggers in WJB are so important.
Ease of Configuration
WJB offers an easy-to-use configuration UI that makes quick work of setting up and managing triggers. Here’s a sample of some of the simple options that put you in control of how the system sends a trigger…
Make Events Prevent Triggering
Select the ‘blacklist’ events that will prevent a trigger being sent from another Bitbucket event, even when triggers are set to fire based on other criteria.
Omit the Branch Name
Easily inhibit the branch name of the commit from being sent to Jenkins.
Omit the Hash Code
Control whether or not the SHA1 hash code from the commit is sent to Jenkins.
Configure by API
As simple as configuration is through the UI, for those who prefer a more automated or programmatic approach, API users can actually change WJB settings directly, through Bitbucket API calls.
Support for Smart Mirrors
Smart Mirrors is a clever tool designed to improve Git performance in Bitbucket for distributed teams that work with large repositories. It allows you to use local mirror instance for Git operations instead of a remote server, which greatly streamlines the performance of commits and other transactions for your organization.
Webhook for Jenkins can also be configured to use Mirrors (as it requires clones for each build), but note that requires the Git Plugin since the Bitbucket Branch Source plugin doesn’t work with Smart Mirrors natively.
Easy Setup
WJB works with the Bitbucket Branch Source plugin, Blue Ocean, or the Git plugin. Configuration differs slightly for each, but once the endpoints are set up, it’s ready to use.
Want more insight to the setup process? Take a look at the straightforward setup process here.
Leveraging WJB for Your Teams
When it comes right down to it, the best way to understand the power and utility of WJB is to experience it for yourself. You can test-drive WJB without spending a dime.
See for yourself how WJB can enhance Bitbucket Server with the power and flexibility of continuous integration provided by Jenkins. Click here to find it on the Atlassian Marketplace.
Whether you’re beginning your transition to a CI model or just looking to shore up those little gaps in automation, WJB macros can help control your bug list, and free up your developers to write code.
WJB remains a prominent staff pick badge and a widely requested plugin on the Atlassian Marketplace.
Everyone at Mohami is excited about the future of Webhook to Jenkins for Bitbucket. We’ve got a ton of features planned, and we hope all of you are as excited as we are.
To find out more about Mohami’s full suite of Atlassian plugins, click here.
