1
00:00:00,440 --> 00:00:02,400
Today we're diving into 
something. 

2
00:00:03,440 --> 00:00:07,880
It might feel a little more 
technical than usual, but it's 

3
00:00:07,880 --> 00:00:11,640
fast becoming a must have for 
business analysts. 

4
00:00:12,400 --> 00:00:18,320
The topic 10 Things every BA 
should know about Git, GitHub 

5
00:00:18,560 --> 00:00:23,200
and how these tools connect with
continuous delivery and 

6
00:00:23,200 --> 00:00:29,240
continuous Integration and a 
Better Business Analysis 

7
00:00:29,240 --> 00:00:32,040
Institute presence. 
The Better Business Analysis 

8
00:00:32,040 --> 00:00:40,920
Podcast with Kingman Walsh. 
Welcome back everyone to the 

9
00:00:40,920 --> 00:00:42,600
Better Business Analysis 
podcast. 

10
00:00:42,640 --> 00:00:47,120
I'm your host, Benjamin Walsh, 
and we are diving into something

11
00:00:47,120 --> 00:00:51,720
that I said was quite technical 
today, and that is get GitHub 

12
00:00:51,720 --> 00:00:54,640
continuous delivery and 
continuous integration. 

13
00:00:55,200 --> 00:00:58,680
Now, you don't need to turn into
a developer overnight, but if 

14
00:00:58,680 --> 00:01:03,520
you want to thrive in agile 
environments, work smoothly with

15
00:01:03,520 --> 00:01:07,280
delivery teams, and understand 
how requirements become real 

16
00:01:07,280 --> 00:01:12,120
software, then Git and GitHub 
are tools you want in your BA 

17
00:01:12,840 --> 00:01:16,400
toolkit. 
So let's countdown the top ten. 

18
00:01:17,960 --> 00:01:23,440
Number one is version control is
for more than just code. 

19
00:01:24,760 --> 00:01:29,320
Git isn't just for developers. 
You can store requirements, 

20
00:01:29,400 --> 00:01:32,720
diagrams, even test cases within
git. 

21
00:01:34,280 --> 00:01:37,480
I once saw business rules 
tracked in git. 

22
00:01:37,840 --> 00:01:42,120
It gave full visibility on who 
changed what and when. 

23
00:01:43,080 --> 00:01:45,120
You can start with Markdown 
docs. 

24
00:01:45,200 --> 00:01:48,640
They're very simple, lightweight
and GitHub friendly. 

25
00:01:49,200 --> 00:01:50,560
And I should say there is a 
difference. 

26
00:01:50,560 --> 00:01:56,480
Git is the kind of protocol and 
GitHub is the kind of main site 

27
00:01:56,680 --> 00:01:59,920
that we use. 
So I you kind of use them 

28
00:02:00,160 --> 00:02:02,800
interchangeably, but they're not
the same thing. 

29
00:02:03,080 --> 00:02:10,600
So GitHub is the most popular 
place to use this #2 is branches

30
00:02:11,000 --> 00:02:17,160
equals safe experimentation. 
Branches, which is branches of 

31
00:02:17,160 --> 00:02:19,360
code or branches of your 
project. 

32
00:02:20,160 --> 00:02:26,120
Let teams work in isolation. 
So an example here could be that

33
00:02:26,120 --> 00:02:30,440
ABA at a bank creates a 
requirements branch for draft 

34
00:02:30,440 --> 00:02:33,840
user stories divisions. 
Review them, comment on them 

35
00:02:33,840 --> 00:02:38,960
before merging, right? 
So there's no lost versions and 

36
00:02:38,960 --> 00:02:40,840
no e-mail clutter. 
You can use it for this. 

37
00:02:40,840 --> 00:02:47,440
So again, it's not just code #3 
is pull requests, which is 

38
00:02:47,440 --> 00:02:50,960
collaboration. 
So pull requests are for 

39
00:02:50,960 --> 00:02:53,600
conversation, not just code, 
right? 

40
00:02:54,080 --> 00:02:58,520
So you can use pull requests to 
validate acceptance criteria 

41
00:02:58,520 --> 00:03:03,920
with divisions and this builds 
trust and I guess it avoids 

42
00:03:04,520 --> 00:03:07,400
mismatches later. 
So pull requests is when you 

43
00:03:07,400 --> 00:03:11,520
pull down the latest version of 
the code set, right? 

44
00:03:11,840 --> 00:03:15,000
So, and for a developer that's 
pulling down all the different 

45
00:03:15,000 --> 00:03:18,440
code changes that they've made. 
So they get to pull the latest 

46
00:03:18,800 --> 00:03:23,600
and GitHub or Git repository is 
where all the code's stored. 

47
00:03:24,080 --> 00:03:27,720
Now, I keep saying code back. 
You think about this, you can 

48
00:03:27,720 --> 00:03:35,320
use exactly the same area to 
store documents #4 is 

49
00:03:35,320 --> 00:03:39,880
traceability through commits. 
So when you make a change to 

50
00:03:39,880 --> 00:03:43,840
your code usually, but it could 
be to your document, you commit 

51
00:03:43,880 --> 00:03:48,480
that code, that document change 
back to the repository. 

52
00:03:49,760 --> 00:03:57,520
So commits are history log and 
you can link Jira or Azure 

53
00:03:57,520 --> 00:04:01,880
DevOps and your stories that are
in them to commits. 

54
00:04:02,440 --> 00:04:05,280
That way the state got to ask 
why something changed. 

55
00:04:05,280 --> 00:04:07,560
You couldn't audit trial. 
So every time you do a commit, 

56
00:04:07,560 --> 00:04:10,200
there's notes and you can 
actually go back to that commit 

57
00:04:10,320 --> 00:04:16,360
and go back in time #5 is that 
there is a concept of GitHub 

58
00:04:16,440 --> 00:04:21,160
issues and projects. 
So GitHub issues are like a 

59
00:04:21,160 --> 00:04:24,200
light, I guess a lightweight 
backlog. 

60
00:04:25,440 --> 00:04:28,960
I've seen BAS use issues for 
user stories, linking them to 

61
00:04:28,960 --> 00:04:31,880
milestones and release planning 
because they're working in an 

62
00:04:31,880 --> 00:04:34,160
environment with a dev team. 
So this is generally something 

63
00:04:34,160 --> 00:04:36,640
you might do. 
If you're working within a dev 

64
00:04:36,640 --> 00:04:40,240
team, you could use the tools 
that they use and GitHub issues.

65
00:04:40,480 --> 00:04:45,680
The GitHub being the platform 
and issues being an area within 

66
00:04:45,680 --> 00:04:48,560
the project. 
If your dev team is already 

67
00:04:48,560 --> 00:04:52,440
using GitHub, meet them there 
instead of forcing them into 

68
00:04:52,440 --> 00:04:57,280
another tool. 
You can also sync the issues in 

69
00:04:57,280 --> 00:05:01,120
there with your issues in Jira 
or DevOps, which of course means

70
00:05:01,120 --> 00:05:06,200
you can use your tool like Jira 
and it will create those issues 

71
00:05:06,240 --> 00:05:08,400
into GitHub. 
There are integrations that do 

72
00:05:08,400 --> 00:05:15,120
that. 
I guess the top tip here is that

73
00:05:15,440 --> 00:05:22,320
GitHub isn't just about vision 
control and storing artifacts 

74
00:05:22,320 --> 00:05:26,960
and version control. 
It isn't just a devs workspace, 

75
00:05:26,960 --> 00:05:29,000
right? 
It's a gold mine for resources. 

76
00:05:29,000 --> 00:05:36,160
So I've thrown this in after #5 
so you can actually go and have 

77
00:05:36,160 --> 00:05:39,560
a look at GitHub and just search
and find some stuff. 

78
00:05:40,360 --> 00:05:46,560
Most cutting edge AI tools, open
source frameworks launch first 

79
00:05:46,760 --> 00:05:50,560
on GitHub so you can explore 
trending repos. 

80
00:05:50,560 --> 00:05:54,120
They're called repositories and 
you might find templates, 

81
00:05:54,120 --> 00:05:57,800
automation scripts, or even AI 
models that can speed up your 

82
00:05:57,800 --> 00:06:03,200
analysis work. 
There is a explore page and you 

83
00:06:03,200 --> 00:06:06,960
can check it weekly on GitHub. 
I do this a lot because I get 

84
00:06:06,960 --> 00:06:10,080
involved in app development and 
I go to GitHub all the time and 

85
00:06:10,080 --> 00:06:12,480
search for a tool. 
For example, if you're looking 

86
00:06:12,480 --> 00:06:16,680
at maybe the latest diagramming 
AI tool for BAS, it will first 

87
00:06:16,680 --> 00:06:18,200
be on GitHub. 
So have a look. 

88
00:06:19,520 --> 00:06:23,480
Let's jump back into #6 and 
that's continuous integration 

89
00:06:23,680 --> 00:06:25,600
CI. 
You may have heard about this 

90
00:06:25,600 --> 00:06:31,720
and not knowing what it is. 
CI means every time something 

91
00:06:31,720 --> 00:06:36,120
changes, they're pushed and 
they're tested automatically. 

92
00:06:36,600 --> 00:06:40,040
But if you think of a dev team 
or a bunch of BAS, but let's 

93
00:06:40,040 --> 00:06:44,560
take devs in this example. 
They're all working on different

94
00:06:44,560 --> 00:06:48,960
areas of code or features within
an application. 

95
00:06:50,040 --> 00:06:52,720
They continuous integration 
allows them to all work on 

96
00:06:52,720 --> 00:06:55,600
there. 
Push those changes into the 

97
00:06:55,600 --> 00:06:59,000
central GitHub repository and 
they're all tested 

98
00:06:59,000 --> 00:07:02,160
automatically. 
If you understand this flow 

99
00:07:02,360 --> 00:07:03,800
right, you just need to 
understand flow. 

100
00:07:03,800 --> 00:07:07,600
You don't need to build the 
pipelines, but you should know 

101
00:07:07,960 --> 00:07:11,280
that when a test fails, a 
requirement might be broken. 

102
00:07:11,280 --> 00:07:15,280
And you it, it has a dashboard. 
So when things get deployed, 

103
00:07:15,440 --> 00:07:17,000
either we'll talk about that in 
a minute. 

104
00:07:17,200 --> 00:07:19,720
This is deployed out to the 
server or production. 

105
00:07:19,920 --> 00:07:23,440
But even the tests, all the 
commits coming, it will show you

106
00:07:23,440 --> 00:07:27,960
if a test failed through CI. 
There's an example here that a 

107
00:07:27,960 --> 00:07:30,960
retail project, right? 
For example, let's say if you 

108
00:07:30,960 --> 00:07:33,600
needed all your acceptance 
criteria, which is your link to 

109
00:07:33,600 --> 00:07:37,280
your requirement? 
If they need to be automatic 

110
00:07:37,280 --> 00:07:42,280
tests and CI or continuous 
integration can expose those 

111
00:07:42,280 --> 00:07:45,440
gaps instantly, right? 
Because you'll see a little 

112
00:07:45,440 --> 00:07:48,680
dashboard and you'll see which 
tests failed. 

113
00:07:50,880 --> 00:07:55,040
Now CD, which is number 7 is 
continuous delivery. 

114
00:07:55,480 --> 00:08:00,520
And CD is about pushing working 
features often and quickly, 

115
00:08:00,720 --> 00:08:01,720
right? 
All about agile. 

116
00:08:02,800 --> 00:08:06,560
This means that you can get 
stakeholder and customer 

117
00:08:06,560 --> 00:08:10,360
feedback fast, and requirements 
are validated in days, not 

118
00:08:10,360 --> 00:08:14,640
months. 
So if you follow Agile to the T,

119
00:08:14,640 --> 00:08:17,600
the whole idea is at the end of 
a Sprint you have a working 

120
00:08:17,600 --> 00:08:20,560
product, an MVP that you then 
iterate on, right? 

121
00:08:20,880 --> 00:08:23,880
And that's where CD comes in, 
because what it means is after 

122
00:08:23,880 --> 00:08:26,960
you've done your CI and 
everything's working, you do 

123
00:08:26,960 --> 00:08:29,360
your CD, which is your 
continuous delivery. 

124
00:08:29,560 --> 00:08:34,919
And in theory at the end of your
Sprint, says the the scrum 

125
00:08:34,919 --> 00:08:38,640
manual, then you are pushing a 
production ready product. 

126
00:08:39,159 --> 00:08:41,960
And that's what CD does. 
It pushes out the working 

127
00:08:41,960 --> 00:08:46,080
product to your server or to 
production to to your customers.

128
00:08:46,280 --> 00:08:48,360
And then they can test it and 
provide feedback. 

129
00:08:48,520 --> 00:08:51,800
So that's what CD is all about, 
doing that again and again and 

130
00:08:51,800 --> 00:08:55,240
just set this up so when you 
make a change and, and, and 

131
00:08:55,240 --> 00:08:58,400
you've made it, you've added 
value by tweaking code or 

132
00:08:58,400 --> 00:09:02,400
changing requirements, whatever 
it is usually code, then it's 

133
00:09:02,400 --> 00:09:05,280
tested automatically through 
continuous integration, making 

134
00:09:05,280 --> 00:09:06,720
sure integration testing is 
working. 

135
00:09:07,040 --> 00:09:09,440
And then CD will push it out to 
production. 

136
00:09:10,600 --> 00:09:13,160
And of course when I say 
production, that could be a a 

137
00:09:13,160 --> 00:09:15,760
test environment, it could be a 
closed beater. 

138
00:09:15,760 --> 00:09:20,960
It doesn't necessarily mean to 
everyone in the public #8 is 

139
00:09:20,960 --> 00:09:25,640
around environment awareness. 
You might hear devs talk about 

140
00:09:25,640 --> 00:09:28,840
devs, staging and production. 
And that's where this world 

141
00:09:28,840 --> 00:09:31,960
connects. 
Learn the difference, the stake 

142
00:09:31,960 --> 00:09:34,800
order tests and staging and says
it's not live. 

143
00:09:35,040 --> 00:09:36,800
You'll know how to explain it 
right. 

144
00:09:36,920 --> 00:09:40,640
And I just talked about you have
different environments and this 

145
00:09:40,640 --> 00:09:45,640
GitHub or Git repositories 
allows you to deploy to these 

146
00:09:45,640 --> 00:09:51,520
various different levels of, I 
guess testing environments, 

147
00:09:51,520 --> 00:09:53,320
staging environments and 
production environments. 

148
00:09:53,320 --> 00:09:55,240
We do various different types of
testing. 

149
00:09:55,560 --> 00:09:59,640
And so that's important and you 
should understand that #9 is 

150
00:09:59,640 --> 00:10:02,120
around data and privacy and 
repos. 

151
00:10:02,120 --> 00:10:05,720
All the repositories for but 
they call them repos for short 

152
00:10:06,400 --> 00:10:10,760
nothing. 
Not everything right belongs in 

153
00:10:10,760 --> 00:10:15,040
GitHub. 
So if you upload real customer 

154
00:10:15,040 --> 00:10:17,080
data, that's a big compliance 
issue. 

155
00:10:17,080 --> 00:10:19,600
You don't put that into GitHub, 
right? 

156
00:10:19,680 --> 00:10:22,080
So you need to be very clear. 
And there's something called get

157
00:10:22,080 --> 00:10:24,520
and nor. 
It's a get and nor file. 

158
00:10:24,520 --> 00:10:27,960
And you will just mark out from 
your repository or your code 

159
00:10:28,160 --> 00:10:31,840
what you don't want to be synced
to this master repository, this 

160
00:10:31,840 --> 00:10:35,360
GitHub. 
So never commit sensitive data 

161
00:10:35,720 --> 00:10:38,320
and you reference it instead. 
So it means that you need to do 

162
00:10:38,320 --> 00:10:42,440
coding properly and you need to 
do records management properly 

163
00:10:42,480 --> 00:10:46,640
and look after your data and you
can reference things like keys 

164
00:10:46,640 --> 00:10:49,480
and secret tech keys that are 
stored away in different areas 

165
00:10:49,720 --> 00:10:52,920
and just read that in your code.
There's all those best practices

166
00:10:52,920 --> 00:10:56,520
in development you will pick up 
as ABA. 

167
00:10:56,520 --> 00:10:58,560
And they're, they're just great 
practice. 

168
00:10:59,360 --> 00:11:04,160
And #10 is mindset changes. 
It's around shared 

169
00:11:04,160 --> 00:11:09,440
responsibility. 
Git, GitHub, CICD aren't just 

170
00:11:09,440 --> 00:11:13,480
dev things, they're team tools 
that you should know about as 

171
00:11:13,480 --> 00:11:17,760
ABA Embrace shared ownership, 
your role is to collaborate, 

172
00:11:17,760 --> 00:11:22,040
trace, and validate that the 
delivery equals business value. 

173
00:11:22,520 --> 00:11:24,960
So you should be embracing and 
learning about these tools. 

174
00:11:26,120 --> 00:11:30,120
So there you have it, 10 things 
every BA should know about Git, 

175
00:11:30,120 --> 00:11:34,800
GitHub and CI and CD. 
From vision control and 

176
00:11:34,800 --> 00:11:39,560
collaboration to using GitHub as
a treasure chest for the latest 

177
00:11:39,560 --> 00:11:44,080
AI tools, these aren't just 
technical extras, they're 

178
00:11:44,080 --> 00:11:47,760
enablers for better 
communication, faster delivery, 

179
00:11:48,280 --> 00:11:50,880
and more credible business 
analysis. 

180
00:11:51,920 --> 00:11:56,040
If you found this useful, share 
it with a fellow BA and I'll see

181
00:11:56,040 --> 00:11:56,960
you next week.