SM, need help on best practices & process you are following with Git/Bitbucket please
Hello All,
My team and I desperately need help with our Bitbucket and release process. Here’s a few details of our team
- Team size of 4
- Our team works with our client team. We develop the front end bit (react), they develop the backend (salesfoce in this instance). The FE obviously relies on the backend for data (viewing/storing/updating etc)
- The definition of done workflow for us is Develop → Raise PR for Internal Code Review → Passed internal code review and merge into ‘dev’ branch which is pushed to a ‘test’ environment ready for internal testing → Internal testing is completed and is now awaiting Internal PO approval → Internal PO approves → Another PR raised for Code Review by Client → Client Code review passed and code is merged into ‘uat’ branch and pushed to a ‘uat’ environment awaiting client PO approval → client PO tests and approves → ticket is marked as ‘Done’
- Working with 3 environments currently - develop, testing, UAT (and will be followed by a Live soon)
My team are really struggling with the whole process. One of the main issues we have is the chaining of code changes. So if User1 changes code, PRs and merges their code in ready for testing, then User2 changes code and get their PR approved. In the meantime User1’s changes are in testing. User2 now is ready to merge changes in, so they pull latest changes including User1 changes. At this point User1’s changes have failed test. Now there’s 2 things that could happen. User2 becomes aware of User1’s test failing. OR Before they are aware of the test failing, User2 has merged their code in and pushed it to test. I’m assuming the above is a common situation. What do you guys do in these cases?
The other case is that we have got code changes merged in one after another. But we have to make the second PR small so that the client team do not have a massive PR to review. What’s the best way to deal with this?
We’ve got branches and release branches all over the place and nothing works. I’m sure we are not the only team working with Git + workflow + DoD. What have you guys found works for you? Can someone please guide us?
Thank you
My team are really struggling with the whole process
I'm not surprised, given that they don't own it. From what you describe they have dependencies on others to get work to Done. This appears to have inhibited your team's ability to adopt a test-driven approach and to improve automation, amongst other things.
I agree with @Ian. Your process has a lot of gates that have to be traversed. In an instance like the one you described, you will have a very had time getting individual changes through the process. It reminds me of all of the gates that I used to face during old waterfall projects where we progressed release candidates that contained a large amount of changes.
Maybe there should be a focus on adapting the process so that there are fewer gates and environments that have to be traversed.
Two things stand out for me.
First, the workflow to "Done" contains things beyond the control of the Developers, and even the Scrum Team. I like to constrain the Definition of Done to things within the control of the team. If that ends up not being sufficient, then I'd try to get more within the control of the team. In your workflow, for example, the team should be able to get work that reaches the client almost certainly able to pass the client UAT. If the client is regularly finding issues, then the team should reflect on why and what they need to do to make sure that they are delivering things that clients find useful.
Second, the dependency on changes is a problem. Branches where you integrate and deploy should always be stable. That is, there should never be a concern with applying User2 changes on top of User1 changes. Failing tests should prevent User1's changes from ever reaching a point where they could be pulled in and interfere with another team. On top of this, the use of techniques such as keystone interfaces and feature flags can help make sure that changes aren't enabled in downstream environments until they are ready, which could help with the flow of changes from development to test to UAT to production - you can deploy the same code but with different feature flag configurations.
My 2 cents are:
Ideally, the team should be organized along the value stream in order to be able to develop the full product from idea to released product. If you do a value stream map, the dependencies will be clear.
That is the people that have the skills needed to develop and validate the product should work in the same team. otherwise you will create dependencies in the "change direction" and increase time to market
I suspect that you may want to revisit your branching strategy. In case the same object is changed in different feature branches, this will become visible when you want merge to master. I have set up bitbucket and bitbucket pipelines so that a feature branch that have passed test automation steps in development and system test environments, can be peer reviewed by another member of the team. Upon approval by that developer in BB Pipelines the change can be deployed to UAT for business validation (this can be automated as well) and deployed to production. This is a Lightweight Change Process based in peer review and team accountability (Reference to DORA/Accelerate Nicole Forsgren). It helped us scale from one release per week to 600 per year and multiple teams.