This is part of our ongoing series about Agile in Practice - Nuve Platform's own iterative journey to ship higher quality software faster.

Setting the Stage: Where We Were

In our previous post in this series we outlined why we needed isolated development environments. Isolated environments definitely helped us to achieve our goals of working and fixing bugs quickly. That led to new, and in our opinion, better, issues.

We could work so quickly in parallel that:

• The number of times that we added code to the main codebase skyrocketed
• We sometimes had two developers working in the same part of the codebase who risked changing the same objects
• We sometimes had to stop developing Feature A based on a new customer request, finish the new Customer Feature, and then go back Feature A when the new Customer Feature was done

We needed a version control system that could handle these types of issues. Taking a page from the web developer playbook, we used the gold standard: GitHub. For ABAP work within SAP, we used abapGit.

This enabled - and continues to enable - our team to work in parallel while preventing collisions. With these workflows we can collectively contribute multiple features per day to the codebase.

How We Initially Used GitHub

GitHub is a tool. It doesn't do everything for us. We needed to agree on a DevOps workflow for how GitHub would be used by the team.

There are many options for workflows with the most common being:

• GitHub Flow - The simplest, and what we used initially
• GitFlow - Complicated but provides benefits for QA and versioned releases
• GitLab Flow - Also complicated with different benefits from GitFlow

We included links to the main workflows above, but here's some very practical advice:

Start with GitHub Flow first, like we did, then work toward GitFlow or GitLab Flow iteratively, if necessary.

If you fail to heed the above advice, your team may reject git and GitHub because adopting it will become confusing.[1]

GitFlow in Brief

In diagram form, it looks like this (Image source):

The idea is really simple, and that is it's appeal.

• The team has one main main branch (in blue, above), which is the most up-to-date version of the code
• Team members create little feature branches off of main (the reddish, green, and yellow dots), which are small to medium sized code changes that are isolated from the main branch.
• When feature branches are ready and tested, team members merge them into the main branch so everybody else can access them
• Team members release the main branch code regularly to a demo, qa, or production environment, depending risk tolerance and other factors.

Read this post to get a full overview of GitFlow.

Aside On Adoption of Tools and Workflows: An Agile Anecdote

We adopted Git because we saw the benefits and we needed them. Forcing Git (or Agile, or whatever) onto a team rarely works well.

When trying to switch to a new tool or agile practices, some people think, "Oh we'll just start using GitHub (and a ticketing system, and arrange our work in sprints, and use words like "scrum" and "retrospective" and . . .) and voila! We'll be agile!"

That's not how it works in practice. Agile is an adaptive process. It's not an idea that that you transplant into a team that makes them instantly faster and more responsive to customers.

The agile process behind adding GitHub might arise like this in a team discussion.

Sally: "We did a great job parallelizing development by giving a separate dev system to each developer."

Jeff: "Yeah I can work so fast now! It's great! But there's a problem . . ."

Sally: "What's happening?"

Jeff: "Well Joe and Swati and I are now making so many changes that we're spending our time trying to keep track of changes and resolve issues when two of us have changed the same thing.

Joe: "Yeah it's like super nice to be able to just do my work, but then I have to check with everyone on the team when we want to put things together into a release."

Sally: "Are there any ways to solve this?"

Joe: "Oooo we could build a cool version control or code transport system . . ."

Swati: " . . . or trust other people have already solved that issue and we could use the existing solution. It's called git. And I can show you all how to use it. It takes less than a day to set it up. I can take the lead."

Sally: "That sounds great. Joe and Jeff?"

Joe: "Let's try it."

Jeff: "Agreed."

An issue that arose organically led to a solution that addresses the issue, which happened to be GitHub in this situation. This conversation would usually take place during a retrospective and then be adopted or rejected within a couple of days to a couple of weeks.

This process leads to buy-in from the team because they all generally agree on the problem they are trying to solve and can check whether this proposed solution fixes the issue. The need for change is obvious and the team shares ownership trying to fix the issue.

What you would NOT do in agile is schedule planning meetings for a month to generate a bunch ideas and then plan out a roll out process and then try to and execute it according to a schedule. The agile team will have tested the first version of a possible solution before many teams even schedule a planning meeting.

Summary of Our Recommendations for Adopting Git

Our practical recommendations are straightforward.

When To Start with Git

When the situation calls for it. Some examples:

• You want to be able to make more small changes quickly and test as you go
• You have so many changes entering your codebase that you are spending too much time dealing with those changes
• You have multiple people trying to work with the same part of the codebase at the same time
• Etc.

Suggested Workflow

Start with GitFlow. It's easiest.

Start with very small changes - one line bug fixes are great. That enables the team to learn the git workflow with lots of quick reps.

Suggested Repo Hosting Provider

GitHub is more popular, but Bitbucket is fine.

Where to Deploy the main Branch

This is the most challenging question, but here are the general principles.

Deploy to Production if Possible

If the system is relatively low risk and or you can make bug fixes really quickly, deploy to production.

Otherwise, Do the Following

Deploy it as close to production as you can without disrupting your critical QA steps. We frequently see people with big enterprise systems creating pre-dev isolated environments, then deploying to the old dev environment to retain the option to switch back to the old dev methods. Then as they gain confidence with pre-dev and git, they remove the shared dev environment and deploy directly to QA.

Where to Go for Support

Basically any decent to excellent web developer who has worked on a team has worked with GitHub. There is no shortage of consulting or full time talent available. Just pick someone who can communicate clearly and can demonstrate the essentials to you.

Finally, Some Weird Language Which You'll Get Used To

As you're reading about git for the first time, it's easy to get lost in terminology, so here's a little cheat sheet to help you out, illustrated though a quick story. The key vocabulary is in bold.

When I first start working in with a codebase that is hosted on GitHub, I need to clone - exactly what it sounds like - the repository - the whole codebase plus all of the stuff below - into the system where I will make changes to the code.

It's interesting to note that the repository contains the full history of all changes to the codebase, in the order in which those changes were made.

When I want to make my first changes to the code I will:

• Create a branch - much what it sounds like, it's the code frozen at the point where you will start making changes, and all changes made to that branch will not affect the code outside of the branch - most likely off of the main branch
• Checkout that branch - so that you are making experimental changes on the branch and not on the parent code of that branch, which other people might need to copy

Now that I'm on the branch, I want to do the following:

• Make any experimental changes that I want and then commit them to the branch, which basically means I am saving the changes (known as diffs) to the branch with a checkpoint
• Push those changes to my branch on origin which will save the changes I made in the github hosted cloud
• When I'm confident in my changes I can open a pull request, which allows other developers to read my proposed changes, comment on them, approve them or request changes
• When the changes are approved I can merge them into the main branch so they become available to all other users

Then I can do the following:

• Delete my branch
• Checkout the main branch
• Pull the updates that I just merged into the github main branch into my system's main branch

That's literally the whole GitFlow step-by-step. Yes it's a lot, but we promise it becomes second nature after a couple of attempts.

[1] We started with GitHub Flow and over time have iterated to using part of the git-flow workflow. While making all of those changes, we have still preserved the core GitHub Flow for 90%+ of our development work.