You would be hard-pressed to find a development team in this day and age that doesn’t leverage source control management software to track changes to their code. As a crucial aspect of effective application and project management, the value of source control cannot be overstated.
Below, we will discuss the concept of source control, the origin of Git, and a process called “GitHub flow” (a popular workflow for development and collaboration when using GitHub). Furthermore, we’ll touch on how Livecycle can help non-developer team members participate in GitHub flow, thereby enabling teams to deliver value to end users as efficiently as possible.
Git, GitHub, and the Importance of Source Control Management
Source control management software allows development teams to track modifications to source code, providing a historical view of all changes made to a particular application over time. This visibility is invaluable. For instance, when problematic changes have been introduced in a deployment, source control provides a view of what exactly changed and when. This can help simplify root cause analysis.
In addition to providing visibility into how an application has evolved, source control tools provide functionality that enables developers to resolve incidents of conflicting changes as they work together on a single code base. This enables developers to collaborate effectively as they make concurrent changes to an application. With this, teams are empowered to move more quickly in the development and delivery of valuable features to their end users.
Git serves as one of the most popular source control tools in use today. Originally developed by Linus Torvalds, Git was built as a distributed version control system, keeping in mind the pain points of the source control tools that preceded it. Since its inception in 2005, a variety of services have been launched to help improve the development process for those who wish to leverage Git repositories to store and manage their source code.
GitHub is a very popular cloud-based hosting service that lends itself to a lightweight branching workflow that many teams find useful for streamlining their development process. Let’s dig into the GitHub workflow — including what it is and how it can facilitate effective collaboration amongst developers.
The GitHub Workflow
The GitHub workflow or “GitHub flow” is a highly beneficial workflow for teams who value the advantages provided by branching, but are also interested in deploying their application with great frequency. GitHub flow consists of a main branch, feature branches (where the actual development is done), pull requests (which enable other members of the development team to review changes), and merging.
The Main Branch
The main branch, historically known as the master branch, is the default branch for a repository. It is created when the repository is created in GitHub. The main branch should always be in a deployable state. This means that developers won’t be actively pushing modifications directly to this branch. Instead, teams should be using feature branches that can then be merged into ‘main’ once the necessary changes have been completed and confirmed to be in working order.
Branching for Bug Fixes and New Feature Development
As mentioned above, feature branches are where the actual development work will be done. When teams discover a bug, or when developers begin working on a new feature, they will create a new branch off of the main branch (in other words, the main branch serves as its base). The work done within a particular feature branch should be very narrow in scope, and teams should only make changes that are necessary to accomplish the task at hand.
Developers are free to commit and push changes to these feature branches as they work. Since this branch is separate from the main branch, these changes will not impact the main branch, which will therefore remain in a deployable state.
Pull Requests
A developer working on a feature branch will need to open a pull request to have his or her changes reviewed and merged into the main branch.
A pull request in GitHub comes equipped with functionality that allows for reviewing and commenting on the proposed changes. This collaborative process helps prevent the introduction of problematic code into the main branch, thus helping to preserve application quality. After the modifications have been reviewed and deemed satisfactory, the changes made to the feature branch can then be merged into the main branch.
GitHub Flow in Practice
To better summarize GitHub flow, let’s consider an example. Imagine that a new feature (Feature A) needs to be developed in an application.
- The first step is to create a new branch off of the default branch (‘main’) in this repository. This branch (let’s call it ‘feature-a’) is where all development will occur.
- The developer responsible for coding Feature A can check out the ‘feature-a’ branch and begin working. While making changes locally, he or she can commit and push changes to this branch at will.
- Next, the developer can open a pull request. As part of this pull request, other developers can participate in reviewing and validating the changes made in the ‘feature-a’ branch.
- Once the modifications are deemed satisfactory, the ‘feature-a’ branch is merged back into the ‘main’ branch. At this point, the ‘feature-a’ branch can be deleted. The diagram below depicts this process.
Where Livecycle Can Help
At this point, all of us should either be rooting for the explained development workflow or thinking about better alternatives. For those of you who are already practicing or considering utilizing the suggested Git workflow for feature development, let’s look at how can we take team velocity to the next level by doubling down on it with even more stakeholders within your company.
How Livecycle Fits Into the Git Workflow
In the outlined workflow, you can look at the moment a new Pull-Request is opened by a developer as the ‘Ready for review’ moment. Developers are actually asking for feedback from their peer developers before they merge the code changes back to the ‘main’ branch.
By piggybacking the same moment in time, Livecycle creates a sharable and isolated environment that allows practically anyone on your team to experience the latest changes on their own.
As can be seen in the illustration below, Livecycle is acting as a bridge between coders and other stakeholders. Creating a visual preview of the latest changes based on the created Pull-Request.
By building and hosting a representative version with more stakeholders you can shift-left the review gathering process, or as we like to call it, have an inclusive Pull-Request workflow.
The Livecycle Impact on the Git workflow
Let’s focus on the moment you’ve got a code review from your peer, made amends with the comments, and move forward to merge this PR to the ‘main’ branch.
For many developers, this is the end game. They can move forward with their lives and pursue another riddle for them to solve. IRL this is not the case as once you have merged your code the feedback loop is just getting started. Get ready to find yourself in discussions with your designer, product manager, QA, and other teams in the company.
Needless to say that any feedback will potentially require you to stop working on the newly created feature branch as you’ll have to handle the needed changes and improvements.
You’d most likely create another branch for fixes or hop on board an already created branch just to move forward quickly and get back to your main focus. No matter which path you’ll choose, you still experience the symptoms of ‘context-switches’ fatigue.
The premise of Livecycle is to refrain from these context switches by gathering all required changes by ALL stakeholders during the time you are in context.
We can summarize the impact with these value propositions:
- Reduce context-switches → Once you merge your feature branch you can actually move forward once and for all.
- Instant review gathering → Control and Invite the feedback whenever you need it (just as you do with peer developers when asking for code review)
- Reduce ambiguity of branches and maintain a clear Git structure
- Automatically create an audit trail for all needed feature changes by all stakeholders in the company
- Always on reproduction environment for every commits → Making your SCM an application time machine.
Will Other Stakeholders Play Along?
We’ve covered some great benefits for developers and now it is time to ask, will other stakeholders actually play along? They are less aware of the Git workflow and potentially don’t even have a user for GitHub or any other SCM in use.
Let’s start by analyzing what are the alternatives for non-developers to share their feedback and when can they share it nowadays.
- Timing - Currently other stakeholders can share feedback only once the feature-branch has been merged already to the ‘main’ branch. They rely on having a usable version deployed to the company’s Staging or Production where the feature is behind a feature-flag for the latter case.
- Context - Since the feedback is based on a non-isolated environment, other stakeholders will probably require either a deeper explanation on what should be reviewed (in the case of a code review, developers have the context as they see which code was changed) or they will simply provide feedback on non-related issues that are out of the feature context.
- Tracking - Most of the feedback is being tracked by the team’s task management tool, meaning outside of your Git provider hence the coupling between them is non-trivial.
By providing these stakeholders an earlier and easier way to experience the latest feature and guiding them to the things they should review, you actually save their time and can make more decisions faster as a team. All they have to do is to enter a link (which is what they do nowadays anyway) and provide feedback on top of the live product contextually. Since all feedback items are within the PR-driven deployed version, the team can also track which items were resolved and have a discussion on the ones that weren’t.
The bottom line here is that ease of use along with a standardized feedback process can achieve the wanted benefits for developers AND other stakeholders at the same time.
