Version Control for Pharma: A Comparison of Gitflow and Trunk-based Development
Ever found yourself lost in a maze of file versions? Something like:
script.R script-edit.R script-edit-reviewed.R
Yes, we all have. Now, let’s imagine that there’s a team of developers working together on an application, and the work is split between them. Once finished, they create its final version as a combination of all the files. It is highly probable that they will encounter problems and spend a lot of time merging their code without getting a desirable result in time. This delays code reviews, feedback and results in lots of refactoring for reasons like code repetitions. That’s where version control comes in.
In this article, we will discuss version control through the lens of Gitflow and Trunk-based development and how the right version control strategy can be a catalyst in trimming down development timelines and elevating the quality of deliverables, which is especially important in the stringent regulatory environment of pharmaceutical development. Understanding these frameworks is important for ensuring efficient and cost-effective project execution.
- Version control systems like Gitflow and trunk-based development allow developers to work on multiple versions of a codebase simultaneously, which can improve efficiency and reduce risks.
- The feature branches approach, also called Gitflow, is a version control system where developers create new branches for each feature and merge them back to the main branch when complete. This approach offers control and code quality, but it can slow down development and cause merge conflicts.
- Trunk-based development (TBD) is a version control system where developers work on a single branch and push code directly as soon as possible, resulting in faster code delivery and reduced merge complexity.
- Trunk-based development is a good version control strategy for pharmaceutical teams because it provides clear audit trails, enables faster time to market, and a more responsive codebase.
Version control introduces the concept of branching. Branching lets you have multiple versions of a code next to each other. One branch is considered to be definitive or the master copy, while additional branches are created for working through changes.
When discussing branching, it is important to emphasize the importance of version control, especially in the regulated pharmaceutical development industry, where every code change has compliance implications.
However, in the spirit of agile, let’s also look for improvements to the process. One of the alternative approaches is to deliver and merge small pieces of work relatively fast and directly with the main codebase. Frequent integration of increments reduces the risk of duplication painful merges and speeds up feedback collection for the final version of the application.
Now, let’s take a closer look at these two version control systems – Gitflow and trunk-based development, that most programmers leverage in quality software development.
The first main pattern for developers to work together is the feature branches approach, also called Gitflow.
In this classic approach, a new branch for each feature is created from the main (master, trunk) one, and then development is performed on it until the built feature is complete and ready to be merged back to main.
Curious about Git-backed deployment with Posit Connect? Appsilon’s Vedha Viyash takes you through a comprehensive tutorial!
The branches are long-lived. There is the primary branch – main, and the secondary one – develop.
The primary branch has restricted access to prevent the introduction of bugs. New features are built on dedicated, individual feature branches originating from develop. Once the work is completed, the pull request is created. The assigned developer reviews and comments on the changes, accepting them or requesting some updates. When there are already a few changes awaiting, they can be released via the release branch. Once reviewed and tested thoroughly, the increment is merged into the main branch and published.
Below, you will find a simple Gitflow branching diagram presenting a general process flow:
The feature branch approach offers you control of the entire process. Before merging, the change is reviewed by authorized developers to ensure good code quality and bug elimination. However, it comes with the cost of time. It may slow down the software development, and the features that are developed separately might cause additional problems when merging to the main code base. Moreover, the code review focuses on newly introduced changes, leaving the improvement of the whole code base untouched.
The second version control management practice is called trunk-based development (TBD). The developers work on a single branch – trunk (main), where they push code directly as soon as possible. They can create short-lived branches with a few small commits.
In this scenario, as the changes are small and frequent, the deployment might happen several times a day. The main advantages of this approach are the speed of code delivery and the reduction of the complexity of the merging events.
Trunk-based development work is required when implementing continuous integration (CI), which ensures good code quality by running fast automated tests. The developed changes are mostly really small compared to the feature branch ones, eliminating long iterations. Moreover, the approach forces the developer to keep the process green – up and running and immediately fixing it if it fails. Commits must not destroy the mainline.
Below, you will find a simple trunk-based development workflow:
Trunk-based development allows teams to release code quickly and consistently. Here are some practices that might help you optimize the development time:
- Small batches
Divide your work into small chunks. Keeping the commits small makes the tempo of merges and deployments rapid. Moreover, minor changes in terms of code lines are easier to review and result in quick decisions.
- Flag your features
Feature flags/feature toggles that are if-statements in the code base allow developers to enclose the changes into an inactive piece of code. When using such flags, you can merge the code into the trunk even if the feature isn’t fully complete or tested.
A robust testing process is required in order to ensure that any code change does not break existing functionalities. All developed features have to be covered by tests.
- Code review
In order to catch any potential issues, it is recommended to perform regular code reviews before merging any changes into the main branch. Moreover, putting together a unified standard of code review is helpful in meeting all the requirements.
As all developers work on the same main branch, it is important to introduce effective communication so that all team members are well-informed and aware of any changes. It ensures that the collaboration between developers is efficient and successful. Besides that, TBD requires developers to have a higher level of discipline so that the development process is followed in the correct way.
In trunk-based development, the automation of building, testing, and deploying the code base are key features. It does not only speed up iterations but also reduces the chance of breaking the code on the main branch. When setting up the test strategy, it is important to remember that it should not block the development and iteration cycle. Additionally, by automating the deployment stage, we make it more resilient to errors.
Gitflow vs Trunk-based development
Gitflow and trunk-based development have different approaches, however, both have their own benefits.
The simplicity of the TBD over classic Gitflow, as well as its fast feedback loop, reduced number of merge conflicts, and alignment with CI/CD practices, is an interesting alternative for teams in pharmaceutical companies looking for agile and robust development workflows. Also, Trunk-based development (TBD) workflows are transparent and traceable, which is important for pharmaceutical companies because they need to be able to track changes to their codebase and provide clear audit trails for regulatory inspections and submissions.
Gitflow typically involves multiple developers and takes days of work. They create feature branches and delay the merge to the main one until the work is completed. Besides, multiple other branches exist – main, develop, release, hotfix.
In the trunk-based approach, development lasts no more than a few hours, and developers merge their changes into one main branch frequently.
Extensive release management processes with multiple stakeholders involved will benefit from Gitflow. On the other hand, trunk-based development will be ideal for continuous deployment workflows. This enables more streamlined and frequent integrations, which can be crucial for pharmaceutical workflows where timely delivery and rapid response to changes are imperative for maintaining regulatory compliance and achieving operational efficiency.
By ensuring all pull requests are managed, Gitflow allows strict control of all introduced changes. The best example of using such an approach is an open-source project or a large project with multiple contributors.
On the other hand, TBD gives less numerous teams of developers flexibility and empowerment. Small commits make the code review an efficient process and easier to complete compared to the review of a long-lived feature branch.
Trunk-based development works well when you are developing a minimum viable product thanks to maximum speed and minimum strings attached, allowing for a quick iteration. The exploration phase of the product is also a great opportunity to introduce trunk-based development.
Gitflow separates branch lines for development, releases, and hotfixes, introducing the complexity of merging strategies. Although it provides an organized structure, it can also lead to infrequent merges with integration issues that are hard to resolve. TBD, with its simplicity, focuses on maintaining the main branch stable, up-to-date, and immediately ready to deploy.
Where to start with trunk-based development?
If you consider introducing trunk-based development in your project, especially within the pharmaceutical space where rigorous testing and compliance are required, here are some recommendations on how to begin:
- Introduce the concept, explain advantages and disadvantages
- Set up robust testing procedures, including automation, to ensure compliance with pharmaceutical quality standards
- Agree on code review rules
- Establish a process for resolving conflicts and merging code changeshttps://posit.co/blog/git-backed-deployment-in-posit-connect/
- Make smaller and more frequent code changes
- Monitor and adjust the process
- Establish a robust versioning system ensuring a transparent, traceable record of every code modification
Summary of Git and Version Control
The usage of Git brings efficiency, testing, automation, and transparency to agile software development. Tracking all changes and the possibility of reversing them when necessary allows the development of high-quality software.
Version control enhances teamwork and enables easy tracking of the project history. It is a crucial tool for distributed teams developing software together. The choice of version control workflow impacts not only the code but also the process of planning the development of features, releasing code, and fixing potential issues. In the end, this choice depends on the project scope, team experiences, and goals, as well as its flexibility and efficiency. Nevertheless, both workflows presented in this article speed up the delivery of the code, thus reducing the cost.
While Gitflow offers a structured, controlled approach conducive to extensive release management, Trunk-based development encourages a fast-paced, continuous integration and delivery, fostering a culture of swift testing and deployment – core attributes that resonate with the dynamic, compliance-driven needs of the pharmaceutical industry.
Transform your pharmaceutical projects with Appsilon’s cutting-edge software development solutions. Schedule a free consultation with us to learn more.