October 1, 2025 • 12 mins
In this episode of the Better Business Analyst Podcast, Benjamen Walsh shares 10 things every BA should know about Git, GitHub, and Continuous Delivery/Integration.
From version control for requirements to collaborating via pull requests, and even how GitHub can be your go-to place for the latest AI models and open-source tools — this episode breaks down the essentials every modern BA needs.
Perfect if you’re working in agile teams, or just want to boost your technical confidence.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Today we're diving into something.
It might feel a little more technical than usual, but it's
fast becoming a must have for business analysts.
The topic 10 Things every BA should know about Git, GitHub
and how these tools connect withcontinuous delivery and
(00:23):
continuous Integration and a Better Business Analysis
Institute presence. The Better Business Analysis
Podcast with Kingman Walsh. Welcome back everyone to the
Better Business Analysis podcast.
I'm your host, Benjamin Walsh, and we are diving into something
(00:47):
that I said was quite technical today, and that is get GitHub
continuous delivery and continuous integration.
Now, you don't need to turn intoa developer overnight, but if
you want to thrive in agile environments, work smoothly with
delivery teams, and understand how requirements become real
(01:07):
software, then Git and GitHub are tools you want in your BA
toolkit. So let's countdown the top ten.
Number one is version control isfor more than just code.
Git isn't just for developers. You can store requirements,
(01:29):
diagrams, even test cases withingit.
I once saw business rules tracked in git.
It gave full visibility on who changed what and when.
You can start with Markdown docs.
They're very simple, lightweightand GitHub friendly.
And I should say there is a difference.
(01:50):
Git is the kind of protocol and GitHub is the kind of main site
that we use. So I you kind of use them
interchangeably, but they're notthe same thing.
So GitHub is the most popular place to use this #2 is branches
(02:11):
equals safe experimentation. Branches, which is branches of
code or branches of your project.
Let teams work in isolation. So an example here could be that
ABA at a bank creates a requirements branch for draft
user stories divisions. Review them, comment on them
(02:33):
before merging, right? So there's no lost versions and
no e-mail clutter. You can use it for this.
So again, it's not just code #3 is pull requests, which is
collaboration. So pull requests are for
conversation, not just code, right?
(02:54):
So you can use pull requests to validate acceptance criteria
with divisions and this builds trust and I guess it avoids
mismatches later. So pull requests is when you
pull down the latest version of the code set, right?
So, and for a developer that's pulling down all the different
(03:15):
code changes that they've made. So they get to pull the latest
and GitHub or Git repository is where all the code's stored.
Now, I keep saying code back. You think about this, you can
use exactly the same area to store documents #4 is
(03:35):
traceability through commits. So when you make a change to
your code usually, but it could be to your document, you commit
that code, that document change back to the repository.
So commits are history log and you can link Jira or Azure
(03:57):
DevOps and your stories that arein them to commits.
That way the state got to ask why something changed.
You couldn't audit trial. So every time you do a commit,
there's notes and you can actually go back to that commit
and go back in time #5 is that there is a concept of GitHub
issues and projects. So GitHub issues are like a
(04:21):
light, I guess a lightweight backlog.
I've seen BAS use issues for user stories, linking them to
milestones and release planning because they're working in an
environment with a dev team. So this is generally something
you might do. If you're working within a dev
team, you could use the tools that they use and GitHub issues.
The GitHub being the platform and issues being an area within
(04:45):
the project. If your dev team is already
using GitHub, meet them there instead of forcing them into
another tool. You can also sync the issues in
there with your issues in Jira or DevOps, which of course means
you can use your tool like Jira and it will create those issues
(05:06):
into GitHub. There are integrations that do
that. I guess the top tip here is that
GitHub isn't just about vision control and storing artifacts
and version control. It isn't just a devs workspace,
(05:26):
right? It's a gold mine for resources.
So I've thrown this in after #5 so you can actually go and have
a look at GitHub and just searchand find some stuff.
Most cutting edge AI tools, opensource frameworks launch first
on GitHub so you can explore trending repos.
(05:50):
They're called repositories and you might find templates,
automation scripts, or even AI models that can speed up your
analysis work. There is a explore page and you
can check it weekly on GitHub. I do this a lot because I get
involved in app development and I go to GitHub all the time and
search for a tool. For example, if you're looking
(06:12):
at maybe the latest diagramming AI tool for BAS, it will first
be on GitHub. So have a look.
Let's jump back into #6 and that's continuous integration
CI. You may have heard about this
and not knowing what it is. CI means every time something
changes, they're pushed and they're tested automatically.
(06:36):
But if you think of a dev team or a bunch of BAS, but let's
take devs in this example. They're all working on different
areas of code or features withinan application.
They continuous integration allows them to all work on
there. Push those changes into the
central GitHub repository and they're all tested
(06:59):
automatically. If you understand this flow
right, you just need to understand flow.
You don't need to build the pipelines, but you should know
that when a test fails, a requirement might be broken.
And you it, it has a dashboard. So when things get deployed,
either we'll talk about that in a minute.
This is deployed out to the server or production.
(07:19):
But even the tests, all the commits coming, it will show you
if a test failed through CI. There's an example here that a
retail project, right? For example, let's say if you
needed all your acceptance criteria, which is your link to
your requirement? If they need to be automatic
tests and CI or continuous integration can expose those
(07:42):
gaps instantly, right? Because you'll see a little
dashboard and you'll see which tests failed.
Now CD, which is number 7 is continuous delivery.
And CD is about pushing working features often and quickly,
right? All about agile.
(08:02):
This means that you can get stakeholder and customer
feedback fast, and requirements are validated in days, not
months. So if you follow Agile to the T,
the whole idea is at the end of a Sprint you have a working
product, an MVP that you then iterate on, right?
And that's where CD comes in, because what it means is after
(08:23):
you've done your CI and everything's working, you do
your CD, which is your continuous delivery.
And in theory at the end of yourSprint, says the the scrum
manual, then you are pushing a production ready product.
And that's what CD does. It pushes out the working
product to your server or to production to to your customers.
(08:46):
And then they can test it and provide feedback.
So that's what CD is all about, doing that again and again and
just set this up so when you make a change and, and, and
you've made it, you've added value by tweaking code or
changing requirements, whatever it is usually code, then it's
tested automatically through continuous integration, making
sure integration testing is working.
(09:07):
And then CD will push it out to production.
And of course when I say production, that could be a a
test environment, it could be a closed beater.
It doesn't necessarily mean to everyone in the public #8 is
around environment awareness. You might hear devs talk about
devs, staging and production. And that's where this world
(09:28):
connects. Learn the difference, the stake
order tests and staging and saysit's not live.
You'll know how to explain it right.
And I just talked about you havedifferent environments and this
GitHub or Git repositories allows you to deploy to these
various different levels of, I guess testing environments,
(09:51):
staging environments and production environments.
We do various different types oftesting.
And so that's important and you should understand that #9 is
around data and privacy and repos.
All the repositories for but they call them repos for short
nothing. Not everything right belongs in
GitHub. So if you upload real customer
(10:15):
data, that's a big compliance issue.
You don't put that into GitHub, right?
So you need to be very clear. And there's something called get
and nor. It's a get and nor file.
And you will just mark out from your repository or your code
what you don't want to be syncedto this master repository, this
GitHub. So never commit sensitive data
(10:35):
and you reference it instead. So it means that you need to do
coding properly and you need to do records management properly
and look after your data and youcan reference things like keys
and secret tech keys that are stored away in different areas
and just read that in your code.There's all those best practices
in development you will pick up as ABA.
(10:56):
And they're, they're just great practice.
And #10 is mindset changes. It's around shared
responsibility. Git, GitHub, CICD aren't just
dev things, they're team tools that you should know about as
ABA Embrace shared ownership, your role is to collaborate,
(11:17):
trace, and validate that the delivery equals business value.
So you should be embracing and learning about these tools.
So there you have it, 10 things every BA should know about Git,
GitHub and CI and CD. From vision control and
collaboration to using GitHub asa treasure chest for the latest
(11:39):
AI tools, these aren't just technical extras, they're
enablers for better communication, faster delivery,
and more credible business analysis.
If you found this useful, share it with a fellow BA and I'll see
you next week.
Today we're diving into something.
It might feel a little more technical than usual, but it's
fast becoming a must have for business analysts.
The topic 10 Things every BA should know about Git, GitHub
and how these tools connect withcontinuous delivery and
(00:23):
continuous Integration and a Better Business Analysis
Institute presence. The Better Business Analysis
Podcast with Kingman Walsh. Welcome back everyone to the
Better Business Analysis podcast.
I'm your host, Benjamin Walsh, and we are diving into something
(00:47):
that I said was quite technical today, and that is get GitHub
continuous delivery and continuous integration.
Now, you don't need to turn intoa developer overnight, but if
you want to thrive in agile environments, work smoothly with
delivery teams, and understand how requirements become real
(01:07):
software, then Git and GitHub are tools you want in your BA
toolkit. So let's countdown the top ten.
Number one is version control isfor more than just code.
Git isn't just for developers. You can store requirements,
(01:29):
diagrams, even test cases withingit.
I once saw business rules tracked in git.
It gave full visibility on who changed what and when.
You can start with Markdown docs.
They're very simple, lightweightand GitHub friendly.
And I should say there is a difference.
(01:50):
Git is the kind of protocol and GitHub is the kind of main site
that we use. So I you kind of use them
interchangeably, but they're notthe same thing.
So GitHub is the most popular place to use this #2 is branches
(02:11):
equals safe experimentation. Branches, which is branches of
code or branches of your project.
Let teams work in isolation. So an example here could be that
ABA at a bank creates a requirements branch for draft
user stories divisions. Review them, comment on them
(02:33):
before merging, right? So there's no lost versions and
no e-mail clutter. You can use it for this.
So again, it's not just code #3 is pull requests, which is
collaboration. So pull requests are for
conversation, not just code, right?
(02:54):
So you can use pull requests to validate acceptance criteria
with divisions and this builds trust and I guess it avoids
mismatches later. So pull requests is when you
pull down the latest version of the code set, right?
So, and for a developer that's pulling down all the different
(03:15):
code changes that they've made. So they get to pull the latest
and GitHub or Git repository is where all the code's stored.
Now, I keep saying code back. You think about this, you can
use exactly the same area to store documents #4 is
(03:35):
traceability through commits. So when you make a change to
your code usually, but it could be to your document, you commit
that code, that document change back to the repository.
So commits are history log and you can link Jira or Azure
(03:57):
DevOps and your stories that arein them to commits.
That way the state got to ask why something changed.
You couldn't audit trial. So every time you do a commit,
there's notes and you can actually go back to that commit
and go back in time #5 is that there is a concept of GitHub
issues and projects. So GitHub issues are like a
(04:21):
light, I guess a lightweight backlog.
I've seen BAS use issues for user stories, linking them to
milestones and release planning because they're working in an
environment with a dev team. So this is generally something
you might do. If you're working within a dev
team, you could use the tools that they use and GitHub issues.
The GitHub being the platform and issues being an area within
(04:45):
the project. If your dev team is already
using GitHub, meet them there instead of forcing them into
another tool. You can also sync the issues in
there with your issues in Jira or DevOps, which of course means
you can use your tool like Jira and it will create those issues
(05:06):
into GitHub. There are integrations that do
that. I guess the top tip here is that
GitHub isn't just about vision control and storing artifacts
and version control. It isn't just a devs workspace,
(05:26):
right? It's a gold mine for resources.
So I've thrown this in after #5 so you can actually go and have
a look at GitHub and just searchand find some stuff.
Most cutting edge AI tools, opensource frameworks launch first
on GitHub so you can explore trending repos.
(05:50):
They're called repositories and you might find templates,
automation scripts, or even AI models that can speed up your
analysis work. There is a explore page and you
can check it weekly on GitHub. I do this a lot because I get
involved in app development and I go to GitHub all the time and
search for a tool. For example, if you're looking
(06:12):
at maybe the latest diagramming AI tool for BAS, it will first
be on GitHub. So have a look.
Let's jump back into #6 and that's continuous integration
CI. You may have heard about this
and not knowing what it is. CI means every time something
changes, they're pushed and they're tested automatically.
(06:36):
But if you think of a dev team or a bunch of BAS, but let's
take devs in this example. They're all working on different
areas of code or features withinan application.
They continuous integration allows them to all work on
there. Push those changes into the
central GitHub repository and they're all tested
(06:59):
automatically. If you understand this flow
right, you just need to understand flow.
You don't need to build the pipelines, but you should know
that when a test fails, a requirement might be broken.
And you it, it has a dashboard. So when things get deployed,
either we'll talk about that in a minute.
This is deployed out to the server or production.
(07:19):
But even the tests, all the commits coming, it will show you
if a test failed through CI. There's an example here that a
retail project, right? For example, let's say if you
needed all your acceptance criteria, which is your link to
your requirement? If they need to be automatic
tests and CI or continuous integration can expose those
(07:42):
gaps instantly, right? Because you'll see a little
dashboard and you'll see which tests failed.
Now CD, which is number 7 is continuous delivery.
And CD is about pushing working features often and quickly,
right? All about agile.
(08:02):
This means that you can get stakeholder and customer
feedback fast, and requirements are validated in days, not
months. So if you follow Agile to the T,
the whole idea is at the end of a Sprint you have a working
product, an MVP that you then iterate on, right?
And that's where CD comes in, because what it means is after
(08:23):
you've done your CI and everything's working, you do
your CD, which is your continuous delivery.
And in theory at the end of yourSprint, says the the scrum
manual, then you are pushing a production ready product.
And that's what CD does. It pushes out the working
product to your server or to production to to your customers.
(08:46):
And then they can test it and provide feedback.
So that's what CD is all about, doing that again and again and
just set this up so when you make a change and, and, and
you've made it, you've added value by tweaking code or
changing requirements, whatever it is usually code, then it's
tested automatically through continuous integration, making
sure integration testing is working.
(09:07):
And then CD will push it out to production.
And of course when I say production, that could be a a
test environment, it could be a closed beater.
It doesn't necessarily mean to everyone in the public #8 is
around environment awareness. You might hear devs talk about
devs, staging and production. And that's where this world
(09:28):
connects. Learn the difference, the stake
order tests and staging and saysit's not live.
You'll know how to explain it right.
And I just talked about you havedifferent environments and this
GitHub or Git repositories allows you to deploy to these
various different levels of, I guess testing environments,
(09:51):
staging environments and production environments.
We do various different types oftesting.
And so that's important and you should understand that #9 is
around data and privacy and repos.
All the repositories for but they call them repos for short
nothing. Not everything right belongs in
GitHub. So if you upload real customer
(10:15):
data, that's a big compliance issue.
You don't put that into GitHub, right?
So you need to be very clear. And there's something called get
and nor. It's a get and nor file.
And you will just mark out from your repository or your code
what you don't want to be syncedto this master repository, this
GitHub. So never commit sensitive data
(10:35):
and you reference it instead. So it means that you need to do
coding properly and you need to do records management properly
and look after your data and youcan reference things like keys
and secret tech keys that are stored away in different areas
and just read that in your code.There's all those best practices
in development you will pick up as ABA.
(10:56):
And they're, they're just great practice.
And #10 is mindset changes. It's around shared
responsibility. Git, GitHub, CICD aren't just
dev things, they're team tools that you should know about as
ABA Embrace shared ownership, your role is to collaborate,
(11:17):
trace, and validate that the delivery equals business value.
So you should be embracing and learning about these tools.
So there you have it, 10 things every BA should know about Git,
GitHub and CI and CD. From vision control and
collaboration to using GitHub asa treasure chest for the latest
(11:39):
AI tools, these aren't just technical extras, they're
enablers for better communication, faster delivery,
and more credible business analysis.
If you found this useful, share it with a fellow BA and I'll see
you next week.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Bobby Bones Show
Listen to 'The Bobby Bones Show' by downloading the daily full replay.