The success of any project hinges on the productivity and satisfaction of its developers: if they are not productive and satisfied, the whole SDLC (Software Development Life Cycle) is doomed to fail. At Blip and in the Flutter group, we are constantly trying to improve our ways of working to ensure we deliver the best Developer Experience (DevXP) possible to our people. Join us in this article as we delve into the main improvements that we are currently working on to unleash the power of seamless collaboration.
Learning how we can uplift our DevXP to unlock the full potential of our development teams in the ever-evolving world of software development is the first step to achieving a seamless collaboration between developers, tools, and processes that pave the way for a new era of software development excellence.
Developer Experience goes beyond the mere availability of programming languages and frameworks. It acknowledges the value of creating a setting where developers can flourish, innovate, and collaborate with ease. By prioritising the Developer Experience, we can increase productivity and produce superior software solutions to meet the constantly expanding demands of the modern digital world. This is especially relevant in organisations like ours, where we have several different teams and brands united for the same goal of building the best products, as is the case of the Global Betting Platform (gbp).
Active Listening to the Community Feedback
When the goals are great, so are the challenges – and sometimes some changes in our processes are necessary so that we can achieve excellence. These changes may involve adapting our processes, procedures and even learning how to collaborate in a different way. To be able to know what to change, we need to be open to feedback, listen to what the community has to say and investigate pain points.
The challenges raised by the community feedback that affected the development life cycle and developer experience included:
- Cross-division tooling dependency;
- Code-reviews bottlenecks;
- Lack of application versioning policies;
- Poor visibility of breaking changes;
- Lack of standard testing documentation.
Starting the Improvement Journey
Proof of concept (POC) workstreams called "Developer Experience Uplift" were started to address the community's feedback. These workstreams sought to pinpoint the underlying causes of the major issues, identify potential technical fixes, outline an ideal target state, and offer high-level estimates of the required work. These workstreams concentrated on the following areas of analysis:
- Continuous Integration (CI) pipeline
- Standardised approach to testing
- Branching strategy
The ultimate objective of these workstreams was to enhance the developer experience overall by enabling developers to create software more quickly, while enhancing productivity and developers' well-being. The feedback from the community was crucial in identifying areas for improvement and set us on a quest to make relevant improvements, with the ambition to have a more streamlined and efficient development process.
Solving Bottlenecks
During the POC, we have come to understand the source of the problems each workstream faced, and we have studied possible solutions to solve them:
- CI Uplift: All CI pipeline was implemented in the heritage Jenkins instance, which caused dependencies on the heritage artefact repository manager. Being the target state to achieve divisional autonomy and prompt and automated feedback on proposed changes, this current divisional dependency could be overcome by implementing the CI pipeline on GitHub Actions and transforming the heritage artefact repository manager into a shared asset. Using GitHub repositories may reduce friction with these internal dependencies.
- Testing: Since most tests depend on the heritage infrastructure to run, a possible solution would be that no component tests depend on the heritage infrastructure and component tests run on GitHub Actions. This would solve the divisional dependency, providing divisional autonomy and prompt and automated feedback on proposed changes (tests).
- Branching Strategy: Currently, release versions are based on Jenkins build numbers without a semantic meaning and an informal Gitflow branching model is being used. This lack of standards problem could be solved by adopting semantic versioning (through SemVer specification) for more meaningful version numbers and to formalise the branching model to Gitflow. This way, we could achieve a set of policies and conventions for a standard application versioning and documentation.
How we Are Transforming the Product Across Divisions
After the POC findings, we have decided on a set of changes so that we can achieve the desired outcomes by implementing the Developer Experience Uplift initiative. It is important to note that the implementation strategy may need to be adjusted based on any unforeseen challenges or obstacles that arise during the process. Additionally, regular monitoring and evaluation of the initiative's progress will be necessary to ensure its success. The implementation strategy has the following goals and dependencies:
Getting Rid of Barriers
By enhancing the way engineers use Git branching, we hope to improve the experience of developers who contribute to gbp. By implementing a multi-team branching model, we can have a standard branching workflow (common SDLC per repository) and a standard versioning format. We were able to determine that the primary gbp Git workflow, Feature Branch, is not robust and flexible enough to gbp's current reality. Gitflow branching's implementation makes it simple and straightforward for teams from various divisions to collaborate.
Removing Dependencies
By using Docker to containerise testing dependencies, we are removing the reliance on the heritage infrastructure and, while at it, removing any dependency from the different UK&I brands and we are fostering testing autonomy. In this manner, we can run testing frameworks separately from divisional tooling in a stable environment. New features can be tested without affecting other divisions thanks to the setup of testing processes and tools. Furthermore, by enabling testing autonomy, we are increasing the speed and efficiency of our testing processes. This allows us to quickly identify and resolve any issues, ultimately leading to a higher-quality product for our customers.
Resolving Access Problems
Moving the CI pipeline to GitHub so that all engineers can have access enables:
- Automated unit and component tests feedback on the pull requests;
- Automated changelog and release notes;
- Additional automated feedback (security, SDLC policies).
Each pull request's automatic feedback creation ensures a higher level of consistency, helping to reduce complexity and provide more context for reviewers. Furthermore, the automated feedback system allows for quicker identification and resolution of issues, as well as increased efficiency in the development process. With these features in place, teams can better collaborate seamlessly and ensure that code changes are thoroughly tested and reviewed before being merged into the main branch.
Improving Testing Documentation
Test documentation can be made readily accessible to all divisions as GitHub files, by condensing it into Markdown files on GitHub. Having the required documentation makes it possible to confidently comprehend, design, and execute tests. Moreover, these practices allow us to keep testing documentation up to date, ensuring all team members are on the same page and can effectively collaborate on testing efforts. This ultimately leads to a more efficient and effective testing process.
Knowing the Risks
As any project entailing a major transformation, there are risks that need to be managed and challenges that need to be overcome, namely:
- Modifications to the SDLC process and tooling may bring on resistance. There is a small risk that the changes will impact current pipelines. It is suggested that teams first test all changes (branching strategy + pipeline addition) in a clone repository before switching over.
- Estimating efforts may be impacted by variations in test automation suite size and complexity of different services and capabilities. CI on GitHub needs to be completely migrated to have full value delivered.
- The full CI value depends on the accomplishment of the other objectives (multi-team branching and testing autonomy). Accurate branching standardisation is essential to CI.
- SemVer was outside the POC's purview, and there are still more unanswered questions. A strong alignment between divisions is necessary for the SemVer migration to work. A partial transition to SemVer with only 5 gbp services adopting it might not have the desired effect.
- There is a risk related to the effort coordination across the different divisions/brands. As we worked in a shared codebase model, these changes need to be coordinated across everyone contributing and any misalignment might lead to overwork.
Where We Stand and What We Have Learned So Far
It is major for us to actively seek and address the challenges that come our way, in order to improve the overall efficiency and effectiveness of our work. By evaluating our bottlenecks, designing, and implementing solutions, and continuously evaluating and adapting processes, our teams can successfully overcome these obstacles and achieve greater success. As we live and learn, while it is important to remember that these adjustments are a normal part of the process and can ultimately lead to greater success as a group, communication channels must be kept open so we can continuously know the team's feel and adjust as we walk together on this journey to build great software for our customers.
If you enjoyed learning more about our developer experience at Blip thus far, check out the job openings we have available and join us!
Soraia Gonçalves
