Is it possible to scan "development" and "UAT" environments in a repo that follows the GitHub Flow pattern?

[Rod-at-DOH]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

Three years ago, another GitHub Admin and I worked on migrating hundreds of TFS repos (TFVC) from an old, on-prem server to our GitHub.com GitHub Enterprise/Organization environment. One pattern, which survives to this day here, is having a branching strategy which mirrors our deployments. Thus, we have a Development branch, UAT (or uat, or test, or Test), and Production (or production) branches. This is so engrained into our culture that the main branch is either ignored or in a few repos, completely removed.

We are beginning a project of incorporating SonarQube into our CI GitHub Workflows. Because of the dominate paradigm, this is easy to do since the test, and development branches are never deleted.

I've known for a long time that it is better to have short lived child branches and only one branch, the main branch, which is the only permanent branch in a repo. I started to learn Git Flow pattern. Then I learned of GitHub Flow, which I now favor. That pattern is very different, treating branches as a means of isolating software development. Whereas environments are for deployments using GitHub environments. But it took me a long time to finally get around to thinking like that, rather than insisting on branches isolate software features in development, and environments control deployments, but all deployments no matter however environments you have, all go through the main branch when deploying. Because it took me so long to rethink that, I lost a lot of mindshare ground, and all the other developers are chasing the proliferation of long lives branches.

If I am to show that software development is isolated in short-lived branches, and environments are used to deploy through the main branches, I will now have to do that using SonarQube. At this point I am not exactly sure how I will do that. I know that if I cannot demonstrate that, then no one will ever consider GitHub Flow.

[kurupdevs]

Correction: the above is only fully true for SonarCloud. SonarQube Server Community Build (the free self-hosted edition) analyzes the main branch only — branch analysis is a Developer Edition+ feature. If you set sonar.branch.name on a non-main branch against Community Build, you get a license warning and the scan falls back onto the main branch, overwriting main's results. So the per-branch setup described below works on SonarCloud (branch analysis included on all plans, free tier included), but on a self-hosted Community Build you'd need Developer Edition for real per-branch analysis of development/uat/production.

Yes, this is absolutely doable — SonarQube (and SonarCloud) treat every branch scan as branch analysis, so your long-lived development / uat / production branches just become long-lived branches in SonarQube too. Nothing about the scanner cares whether your workflow is GitHub Flow or Git Flow.

Two practical things to set up:

1. Trigger the scan workflow on pushes to those branches, not just on PRs. In your workflow YAML:

   on:
     push:
       branches: [development, uat, production]
     workflow_dispatch:

   The workflow_dispatch is handy so you can re-scan a branch on demand without pushing.

2. Let the scanner name the branch. If you're using the SonarQube Scan GitHub Action, it picks up the branch from the GitHub event context automatically (the sonar.branch.name property). For long-lived branches in SonarQube, the first scan of a branch defines the baseline; after that it tracks new code against it. In your SonarQube project's branch settings you may want to designate production (or main) as the main branch for overall project health.

One governance tip given your environment: since you're defending isolated development in short-lived branches plus environment branches, scanning the long-lived environment branches is actually what gives you the audit trail — each environment's scan history shows exactly what was deployed there. That maps nicely onto your TFS-migration narrative about environments being represented by branches.

If you're scanning PRs as well, keep both: PR analysis for pre-merge quality gates, and branch analysis on development/uat/production for environment-level baselines.

[Rod-at-DOH]

Thank you, @kurupdevs, for your feedback! One thing I wasn't clear on, when trying to encourage people here to use short-lived branches, I intend to suggest they delete a child branch both on the remote and locally, when they're done with it.

I believe that even if I use short-lived child branches, that they'll still provide useful data, rather than having long-lived child branches that last years.

You suggestion of performing the scan on workflow pushes to the development, uat, and production branches, isn't one I thought of before. And I like to idea of scanning all 3 child branches in one workflow. I might be able to do that with a repo that follows GitHub Flow, but I doubt that my fellow developers and management would want to follow that pattern. They're so tied to a branch mirrors a deployment, that they want a build to development to happen. Then developers test it over some period of time. Then when the developers are happy, they do another build to uat from development and ask the users to test that for a while. Then when the users are happy, the developers will create a PR to merge uat into production, but only after an approval from a change management board. This process can take weeks. I guess in one way what I'm saying doesn't matter, because none of these SonarQube scans will, at least for now, create a deployment. If incorporating the SonarQube build is made into a job in a workflow, with another job that needs the SonarQube job to finish, then yeah, it will require those multiple delays for testing and approval. In the case of a repo structured to follow the GitHub Flow pattern, I would leave the workflow to run the scans as just that job. And I would want the GitHub Flow repo to create a release and attach the built app to the release.

Lastly, I hadn't even thought of scanning the PRs!

[ssuleimenovv]

@Rod-at-DOH reading your follow-up — I think the real blocker isn't SonarQube, it's the "a branch mirrors a deployment" habit. What helped convince people in my experience: GitHub Flow doesn't remove any of their gates, it just moves them from branches to environments.

Your current process maps pretty much 1:1:

• merge into development → PR merged into main, build once, auto-deploy to the development environment
• devs test, then build UAT → uat environment with required reviewers (dev leads)
• users test + change board approves → production environment with the CAB team as required reviewers, deployment branch restricted to main

Same weeks of testing, same CAB approval, just in Settings → Environments instead of merge PRs. And the same artifact goes to all three environments, so no more "UAT build differs from prod build".

jobs:
  build:        # sonar scan + build + upload-artifact
    runs-on: ubuntu-latest
    steps: [ ... ]

  deploy-dev:
    needs: build
    environment: development
    runs-on: ubuntu-latest
    steps: [ ... ]

  deploy-uat:
    needs: deploy-dev
    environment: uat
    runs-on: ubuntu-latest
    steps: [ ... ]

  deploy-prod:
    needs: deploy-uat
    environment: production
    runs-on: ubuntu-latest
    steps: [ ... ]

Two gotchas:

1. A job waiting for environment approval times out after 30 days. If UAT can take longer, move deployment into a separate workflow_dispatch / release-triggered workflow that deploys a given tag — which also fits your idea of attaching the build to a release.
2. For SonarQube, scan on pull_request too — that's your demo of short-lived branches: each PR gets its own quality gate before touching main. But PR/branch analysis needs Developer Edition or higher; Community Edition only analyzes one branch, so check that before building the pitch around it.

I'd pilot it on one small repo with the same approvers your CAB uses today. People buy it faster when they see their own approvals, just in a different place.

[Rod-at-DOH]

I like the idea of demonstrating shorter-lived child branches on a smaller project. However, as I did mention I had tried doing this before, but one developer assigned to the project ignored what I said when I told him not to do their old habit of multiple branches that never are removed and the associated list of lots of folders (subdirectories). I haven't gone into that before, but it might help explain how when following the old pattern results in locking them into that pattern/mentality.

We use Microsoft's .NET, and I'll restrict myself to web applications. The habit that came about from years of using TFS, was to create a folder named "current". Into that folder goes the current deployment of the website. But all previous deployments are saved on the web server, in folders with names like "YYYYMMDD - ab", where YYYYMMDD is the date of the deployment and "ab" are the initials of whoever generated the last deployment. In practice, these copies of previous "current" folders never are deleted. So, there will be many copies of previous "current" folders, which never get deleted. Having originally lost the argument of why shorter-lived branches are better, I tried to point out that this pattern they've followed for years doesn't leave anyone any idea as to what is in each of the PRs. I just looked at one of our repos for a web app for PRs migrating UAT to Production. Half had a one sentence description of what the PR was about. The other half had nothing describing what the PR was about. I'd estimate that each repo's environment has hundreds of copies of previous "current" for each environment.

[ssuleimenovv]

@Rod-at-DOH that folder pattern is actually a useful clue. Those YYYYMMDD - ab folders exist because people want two things: rollback and a history of what was deployed when. That's a real need, so I wouldn't argue against it. I'd show them GitHub gives them the same thing, just better:

Each deployment = a GitHub Release (tag + the built artifact attached). The release is the YYYYMMDD - ab folder, except it's tied to an exact commit, lists the PRs included, and shows who approved it in the environment history.
Rollback = redeploy the previous release, e.g. a workflow_dispatch that takes a tag and deploys that artifact to current. Once people trust that, the old folders on the server become unnecessary (or the deploy step can just keep the last 3 for comfort).

For the empty PR descriptions:

Add a .github/pull_request_template.md with a few required sections (what / why / how to test).
Use auto-generated release notes (.github/release.yml to group by labels). The release notes are built from PR titles, so bad PRs become visible to everyone, including the change board.
Part of the problem is structural: a UAT → Production merge PR bundles weeks of unrelated work, so nobody can describe it in one sentence. With GitHub Flow each PR is one change, so descriptions naturally become small and meaningful.

For the developer who ignored the guidance, I'd stop relying on persuasion and let the repo enforce it in the pilot:

Settings → General → "Automatically delete head branches" after merge.
A ruleset on main: require a PR, require the SonarQube check to pass, block direct pushes.
Optionally a ruleset that restricts creating branches like development / uat / production*, so the old pattern simply isn't available in that repo.

Then the easiest path is the correct one. And for the demo to the team, the most convincing thing is probably a side-by-side: one of the current repos (hundreds of folders, empty PRs) vs. the pilot's Releases page, where every deployment has notes, a commit, an approver and a one-click rollback.

[Rod-at-DOH]

@ssuleimenovv WOW, this is great information!!! Man, I love how you can use GitHub Flow in so many ways.

You are correct, that the important thing both management and developers who prefer the strategy of multiple branches that never are deleted, is they want the ability to rollback. I'm not sure they want a history of what was deployed, but I could be wrong about that.

You brought up a couple of files I've not heard of; .github/release.yml and .github/pull_request_template.md. WOW, there are so many Markdown files that have specific uses. I'm going to have to try and learn about more of them.

Your latest answer is great, and I think I'll mark it as the answer of this thread. However, I have one more issue which has just come to my attention. This comes from my security officer. The CISO has dictated the following:

1. The Production branch and any production code must never be scanned by SonarQube nor any other scanning mechanism.
2. Only the Development and UAT branches are to be scanned.

Given these orders, the Production, UAT, and Development branches must always exist. Thus, the GitHub Flow paradigm, I believe, cannot be followed.

The Production branch must exist because that one developer who didn't follow my request, has written a significant amount of PowerShell code. One task that code does is check to see what the name is of the branch originating the PR, and if it is one of the 3 branches named in the repo's variables of Production, UAT, and Development, it dictates how the rest of the workflow will work. I'm aware of the fact that it is one line of PowerShell code to see if the branch "Production" can be applied to the "main" branch, but he refuses to put that check into the PowerShell. At this point, and with so many people insisting that multiple branches must exist for all time, I now don't think there's any way I can ever convince them to adopt GitHub Flow. Perhaps there is and you can give me one, so I'll wait to see what you say about this.

I will save your latest reply for myself, to be able to use it at another time.

[ssuleimenovv]

Glad it helped, Rod !

Given the CISO's rules, I think you're right: when Prodiction, UAT and Development all have to exist permanently, pure GitHub Flow isn't a good fit, and that's fine. GitHub Flow is a recommendation, not a requirement. An environment-branch model like yours is a valid choice as long as it's consistent

And whenever you get a chance, feel free to mark the reply as the answer. It'll help others who run into the same question find it faster. Good Luck with it !