The 5 Biggest Time Savers in Bitbucket

[#1]

Boost your productivity in Bitbucket with these top five automation tips. From optimizing pull request reviews to tailoring your CI/CD pipeline, these strategies will streamline your workflow and save you valuable time.

1. Share responsibilities

Reviewing pull requests takes time, so only really invite people relevant to the changes you are reviewing. If you were to always invite everyone to review your awesome new code most reviewers would find sooner or later that they have no responsibility for the modules you have improved, however they have spent the better half of 15 minutes to get there. That’s 8 min wasted times the size of your team.

Time savers:

1. Dynamic reviewers. Try file/module-path sensitive reviewer configurations, and configure different reviewers and groups for different modules.

2. Use reviewer groups, not individual reviewer users, groups act as proxies whose members share the same role/responsibility. If individuals' responsibilities change, just update the group memberships, not entire reviewer configurations across all repositories.

3. Dynamic approvals. Use merge-check approval quotas. Don’t wait for everyone to approve. Oftentimes a couple of reviewer approvals are sufficient. Context-sensitive approval requirements combined with dynamic reviewers can be a massive time-saver for closing out pull requests.

4. Reset approvals selectively. In cases where pull request files are modified midway, such as after addressing review feedback, it may be necessary to reset previously granted approvals. Make your pull request review rules file-context specific for withdrawing approvals. Not all given approvals need to be revoked, only updated files need re-approval from relevant reviewers.

 
file/module-path sensitive reviewer configurations on Workzone

2. Cater for multiple scenarios

As with all things in life, there’s no single rule that fits all scenarios. Ongoing feature development and refactoring requires thorough reviews by senior developers, while bug fixes need require a much smaller reviewer footprint.

Time savers:

1. Use pull request source and destination branch-specific reviewer configurations. Add stakeholders and senior developers (as groups, of course) to feature development pull requests for example from feature/** to main

2. Expedite bug fixes. Merging from bugfix/** to main only needs a couple of approvals from the QA team to validate that the bug was fixed.

3. Keep the emergency lane free

When the sh*t hits the fan in production, teams need to move really quickly.

Life savers:

1. Formulate specific pull request review rules and merge checks that allow for quick decisions and execution. For example, a hotfix/** to main reviewer and merge checks configuration has a big-wigs reviewer group and any of its members can approve and merge the life-saving pull request.

2. Make preliminary build results and code-quality checks optional as they may take up too much time to run and complete.

4. Automate sensibly

Stick to sensible automation instead of automating everything.

Time savers vs wasters:

1. Only automate what you really need to: If you perform a 5 min task every month which would take you 5 days to automate and test - you’re wasting your time. Check out the table below to find out if automating a task makes sense:

   

   Source: https://xkcd.com/1205

2. Automate what you have mastered already. If you know a task or process inside out, automate it! If there’s uncertainty and randomness in the process that needs your intuition and good judgement, don’t automate for the sake of it, just because you can and waste time fiddling with your automation down the track.
   Source: https://xkcd.com/1319
   
   

3. Configure the CI/CD pipeline to perform different levels of building and testing for different stages of the development cycle. When you push code to a feature or bugfix branch, just build and run quick unit tests automatically. When a pull request is created, build and run unit and integration tests on the source branch.

4. Merge pull requests automatically. Don’t wait for someone who might be distracted by more important things to click the ‘Merge’ button on a pull request. Create pull request merge-checks that check build status, approval quotas, resolved tasks etc and as soon as all conditions are fulfilled, merge the pull request automatically.

5. Clean up regularly

Pull requests can get out of date very quickly. While the pull request’s source branch with your work is not evolving its destination branch evolves very quickly as others merge in their work. Sooner or later merge conflicts show up which need to be resolved. We find that resolving merge conflicts is the worst productive time killer out there.

Time savers

1. Prioritise important pull requests over others. Block the merge of less important pull requests to avoid jeopardising high-priority pull requests.

2. Set due dates on pull requests to let everyone know about the merge timeline.

3. Send out time-sensitive reminders to authors, reviewers and stakeholders before the due dates.

4. Scan open pull requests for merge conflicts regularly and send out notifications.

5. Enable automatic pull request decline after an expiration period.

Manage personal and work-related stress

Negative stress is bad. Decreased focus, less concentration, more errors, procrastination, distraction, disconnect, bad communication … all impact your creativity, effectiveness and productivity because you get less done and need more time!

Stress busters

1. Recognise that you are feeling stressed right at this moment.

2. Allow this to be ok - you’re doing great. Everyone gets stressed at times. There’s nothing wrong with you or anyone else, especially your boss.

3. Inquire, pause, take a breath in and oooouuuut - and name a few facts the cause you stress.

4. Nurture and treat yourself for actually doing this little stress-buster-break

Looks like R-A-I-N ? Good news is that there’s always sunshine after R-A-I-N.

As always,

Happy coding everyone

Sean & Ulrich

Izymes