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 with continuous delivery and
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
that I said was quite technical today, and that is get GitHub
continuous delivery and continuous integration.
Now, you don't need to turn into a developer overnight, but if
you want to thrive in agile environments, work smoothly with
delivery teams, and understand how requirements become real
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 is for more than just code.
Git isn't just for developers. You can store requirements,
diagrams, even test cases within git.
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, lightweight and GitHub friendly.
And I should say there is a difference.
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 not the same thing.
So GitHub is the most popular place to use this #2 is branches
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
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?
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
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
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
DevOps and your stories that are in 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
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
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
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,
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 search and find some stuff.
Most cutting edge AI tools, open source frameworks launch first
on GitHub so you can explore trending repos.
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
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.
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 within an application.
They continuous integration allows them to all work on
there. Push those changes into the
central GitHub repository and they're all tested
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.
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
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.
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
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 your Sprint, 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.
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.
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
connects. Learn the difference, the stake
order tests and staging and says it's not live.
You'll know how to explain it right.
And I just talked about you have different environments and this
GitHub or Git repositories allows you to deploy to these
various different levels of, I guess testing environments,
staging environments and production environments.
We do various different types of testing.
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
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 synced to this master repository, this
GitHub. So never commit sensitive data
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 you can 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.
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,
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 as a treasure chest for the latest
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.