In my experience, it can be tricky to add compliance steps and structure to your Bitbucket workflows without killing the flexibility your developers need to get work done. Here’s an insight into how we are trying to strike the right balance between control and flexibility at PAYBACK using ScriptRunner for Bitbucket.
PAYBACK operates in a tightly-regulated, heavily audited environment. And, our fast-growing, on-premise Atlassian stack is the perfect way to ensure coordination and traceability between teams and departments.
Bitbucket was first introduced on a trial basis, as a small instance administered entirely by our developers. In no time, our Bitbucket instance became unwieldy and messy with each development team following different (often conflicting) rules and permissions. Calling on my experience as an Atlassian consultant and as the Automation and Collaboration team lead at PAYBACK, here’s how I tackled the challenge.
Establishing context-based ownership in Bitbucket
At PAYBACK, the general approach for all our Atlassian tools is to allow a certain degree of stakeholder ownership, rather than having strictly centrally managed projects. Following this approach means our users have more freedom within their projects and my team avoids becoming a bottleneck while still ensuring control and compliance (you can read more about this general approach in my previous guest post below).
To achieve stakeholder ownership in Bitbucket, we started by building one generic permission scheme based on three basic context-related roles: Admin, Read-Write and Read.
First, we created three project-based groups to fit the three roles, then we migrated wide-spread permissions from context-unrelated groups into the context-related ones: Admin, Read-Write and Read.
Then, we removed all other permissions from the project configurations, which ensured a 1:1 relation at project level and considerably eased the complexity of our Bitbucket.
The next step was to ensure any project permissions would be unaffected by the change. So, we used the event handler feature in ScriptRunner for Bitbucket to set up four rules:
- Group-adding is restricted to group names that fit our naming convention. (ie. Bitbucket -$projectkey-admin).
- Granting admin-permissions is restricted to the users in admin-group-name.
- Write-permissions have been restricted to the Bitbucket-$projectkey-users group.
- Read-permissions have been restricted to the Bitbucket-$projectkey-users-r group.
We use the ScriptRunner custom event handlers to block any permission actions that go against these rules, presenting a message to users explaining why their action has been blocked.
This way, our context owners in Admin roles have the freedom to grant permissions to other users in their teams. But, the general context-based ownership rules are respected and crucially chaos is avoided.
Auto-adding and checking for approvers
As an extra security precaution, context owners asked us to give them a way in which they could make specific approvers mandatory on certain paths in the code. As this is not something you can do out-of-the box in Bitbucket, ScriptRunner came to the rescue again.
We combined a custom event listener, a custom merge check and a configuration file. The configuration file is placed in the master-branch of a repository to activate both the listener and the merge check. With this combination, context owners are now able to configure single users being added as approvers on paths that can be scoped using regex.
Creating an easy way to notify approvers
Like many other companies, PAYBACK relies heavily on a messaging solution for collaboration - in our case we use WebEx Teams.
We discovered that the easiest way to let approvers know there are new Pull Requests that need approval or Pull Requests being merged, was by triggering chat notifications to separate and context-scoped chat rooms. With notifications being sent out to chat rooms there’s a common “log-like” history for users within this context.
Setting this up in Bitbucket was very easy with the REST endpoints function in ScriptRunner.
Handing back control
I worked closely with our development teams for around six months to ensure Bitbucket was set up and working in the way we wanted, but the end goal was always to hand back control once the ground rules were established - and this is exactly what happened.
As my role is to implement ideas and feature requests coming from our users, ScriptRunner is my go-to tool for creating automations and customisations in Bitbucket. Now, we keep all our ScriptRunner code in Bitbucket, which makes it easy to modify and improve it or to implement new feature requests. As we have passed the ownership back to our development teams, we can give our Bitbucket stakeholders the flexibility they need to implement their own rules via ScriptRunner, with my team acting as sanity control.