WEBVTT

1
00:00:00.120 --> 00:00:03.560
<v Speaker 1>Welcome to the deep dive. We're jumping straight into what

2
00:00:03.600 --> 00:00:08.080
<v Speaker 1>it takes to build and deliver software better, not just

3
00:00:08.160 --> 00:00:11.320
<v Speaker 1>you know, the coding itself, but the whole process getting

4
00:00:11.359 --> 00:00:13.960
<v Speaker 1>it out there efficiently, securely, all.

5
00:00:13.800 --> 00:00:16.440
<v Speaker 2>Of that exactly. And we've got a really rich set

6
00:00:16.519 --> 00:00:19.839
<v Speaker 2>of information we're drawing from mostly this comprehensive guide. It

7
00:00:19.879 --> 00:00:23.640
<v Speaker 2>looks at everything from managing projects right inside GitHub to

8
00:00:23.800 --> 00:00:28.000
<v Speaker 2>some pretty advanced security practices. It even digs into how

9
00:00:28.120 --> 00:00:31.879
<v Speaker 2>team structures well, how they influence the software itself, and to.

10
00:00:31.800 --> 00:00:34.359
<v Speaker 1>Give us a wider perspective, we're also pulling in some

11
00:00:34.399 --> 00:00:37.200
<v Speaker 1>industry reports, articles, that kind of thing. They provide some

12
00:00:37.240 --> 00:00:40.240
<v Speaker 1>real world context, some data to back things up. Yeah.

13
00:00:40.280 --> 00:00:43.399
<v Speaker 2>Absolutely so for you listening, our goal here is to

14
00:00:43.439 --> 00:00:46.520
<v Speaker 2>cut through the noise, really pull out the key insights

15
00:00:46.520 --> 00:00:48.920
<v Speaker 2>on how to well level up your software delivery.

16
00:00:48.960 --> 00:00:50.840
<v Speaker 1>Whether you're writing code, managing.

17
00:00:50.439 --> 00:00:53.600
<v Speaker 2>A team, or maybe just curious about how modern software

18
00:00:53.600 --> 00:00:56.439
<v Speaker 2>development actually works. We're aiming to give you that core

19
00:00:56.560 --> 00:00:59.119
<v Speaker 2>knowledge without burying you in details.

20
00:00:59.320 --> 00:01:02.399
<v Speaker 1>Okay, so the question, the central mission for today is

21
00:01:03.399 --> 00:01:06.959
<v Speaker 1>what are the most effective practices, the best tools that

22
00:01:07.040 --> 00:01:10.599
<v Speaker 1>software teams can leverage right now to speed things up?

23
00:01:10.799 --> 00:01:12.560
<v Speaker 2>Speed up development, speed up delivery.

24
00:01:12.680 --> 00:01:16.359
<v Speaker 1>But and this is key while keeping quality and security

25
00:01:17.120 --> 00:01:19.280
<v Speaker 1>absolutely top priorities.

26
00:01:18.840 --> 00:01:21.480
<v Speaker 2>Exactly, And the guide we're using really kicks off with

27
00:01:21.519 --> 00:01:25.359
<v Speaker 2>this idea, this fundamental point. Software development is a team

28
00:01:25.480 --> 00:01:28.760
<v Speaker 2>sport totally and right at the heart of that teamwork,

29
00:01:29.040 --> 00:01:30.480
<v Speaker 2>you find the poll request.

30
00:01:30.719 --> 00:01:33.959
<v Speaker 1>Ah, the poll request, So when a developer wants to

31
00:01:34.000 --> 00:01:37.280
<v Speaker 1>propose changes, that's the mechanism, that's it. The guide walks

32
00:01:37.319 --> 00:01:41.319
<v Speaker 1>through it, creating them draft prs for work in progress

33
00:01:41.480 --> 00:01:43.760
<v Speaker 1>code owners. Code owners, yeah, saying who needs to look

34
00:01:43.799 --> 00:01:47.239
<v Speaker 1>at what? And required reviews. Obviously can't merge without those checks.

35
00:01:47.280 --> 00:01:49.159
<v Speaker 2>We won't get bogged down in every single click. But

36
00:01:49.239 --> 00:01:50.840
<v Speaker 2>it sets the stage for collaboration.

37
00:01:51.040 --> 00:01:53.519
<v Speaker 1>But what's really interesting is the emphasis on making those

38
00:01:53.560 --> 00:01:54.799
<v Speaker 1>code reviews effective.

39
00:01:54.920 --> 00:01:58.879
<v Speaker 2>Yes, the guide really hammers this home well. Structured commits

40
00:01:58.920 --> 00:02:03.560
<v Speaker 2>are key. Each commit should tackle one single logical change,

41
00:02:04.200 --> 00:02:06.920
<v Speaker 2>and the commit message it needs to be clear what

42
00:02:07.000 --> 00:02:08.800
<v Speaker 2>did you do and why did you do?

43
00:02:08.840 --> 00:02:12.560
<v Speaker 1>It makes total sense trying to review a giant commit

44
00:02:12.719 --> 00:02:16.159
<v Speaker 1>with mixed up changes and a vague message like fixed

45
00:02:16.319 --> 00:02:17.879
<v Speaker 1>stuff forget.

46
00:02:17.560 --> 00:02:22.199
<v Speaker 2>It impossible, right, And it specifically warns against mixing, refactoring,

47
00:02:22.759 --> 00:02:25.639
<v Speaker 2>you know, just cleaning up code with adding new business

48
00:02:25.639 --> 00:02:27.360
<v Speaker 2>logic in the same commit Oh yeah, that.

49
00:02:27.439 --> 00:02:29.560
<v Speaker 1>Just muddies the waters for the reviewer completely.

50
00:02:29.639 --> 00:02:33.240
<v Speaker 2>Keep them separate. Reviewers can focus on the actual functional change,

51
00:02:33.400 --> 00:02:34.919
<v Speaker 2>understand its impacts.

52
00:02:34.560 --> 00:02:38.039
<v Speaker 1>Makes the whole process way more efficient, and you're more

53
00:02:38.120 --> 00:02:39.159
<v Speaker 1>likely to catch issues early.

54
00:02:39.319 --> 00:02:40.960
<v Speaker 2>Exactly, it's just good practice.

55
00:02:41.199 --> 00:02:45.639
<v Speaker 1>Okay, let's think about how teams actually work today. So

56
00:02:45.840 --> 00:02:49.240
<v Speaker 1>often they're spread out right, different places, different time zones.

57
00:02:49.759 --> 00:02:51.280
<v Speaker 2>Distributed teams are becoming.

58
00:02:51.039 --> 00:02:53.120
<v Speaker 1>The norm, and the Guide spends some time on this

59
00:02:53.240 --> 00:02:55.000
<v Speaker 1>shift towards asynchronous communication.

60
00:02:55.240 --> 00:02:57.759
<v Speaker 2>It's interesting if you look at the history communication shifts

61
00:02:57.840 --> 00:03:03.360
<v Speaker 2>used to take generations. Now it feels like every few years, smartphones,

62
00:03:03.439 --> 00:03:09.120
<v Speaker 2>the Internet, it's pushed us towards preferring ACNC stuff quick messages,

63
00:03:09.159 --> 00:03:12.039
<v Speaker 2>emails where you don't always expect an instant reply.

64
00:03:12.280 --> 00:03:14.759
<v Speaker 1>I remember when waiting a day for an email reply

65
00:03:14.919 --> 00:03:17.120
<v Speaker 1>was totally normal. Now it's like, if you don't hear

66
00:03:17.159 --> 00:03:17.560
<v Speaker 1>back in.

67
00:03:17.520 --> 00:03:20.919
<v Speaker 2>An hour, you start wondering, right, But for distributed teams,

68
00:03:21.039 --> 00:03:25.080
<v Speaker 2>that expectation of instant replies that can actually slow things.

69
00:03:24.879 --> 00:03:26.960
<v Speaker 1>Down oddly enough, become a bottle lick.

70
00:03:26.960 --> 00:03:30.879
<v Speaker 2>Hey, exactly, And that's where ACNC workflows really shine. The

71
00:03:30.919 --> 00:03:33.759
<v Speaker 2>guide highlights a few best practices here. One big one

72
00:03:34.240 --> 00:03:37.639
<v Speaker 2>prefer chat platforms over email for work discussions. Why is

73
00:03:37.639 --> 00:03:40.680
<v Speaker 2>that keeps the conversation history all in one place. If

74
00:03:40.680 --> 00:03:43.639
<v Speaker 2>someone's offline, the info isn't just stuck in their personal inbox,

75
00:03:43.960 --> 00:03:45.080
<v Speaker 2>anyone can catch up.

76
00:03:45.159 --> 00:03:49.319
<v Speaker 1>Yeah, email threads could become absolute monsters. The other really

77
00:03:49.360 --> 00:03:52.360
<v Speaker 1>interesting suggestion was making most meetings optional.

78
00:03:52.680 --> 00:03:54.560
<v Speaker 2>Right, this is a big one. It forces you to

79
00:03:54.599 --> 00:03:58.000
<v Speaker 2>ask is this meeting really necessary for everyone invited? The

80
00:03:58.039 --> 00:04:01.000
<v Speaker 2>thinking is if people don't see clear value, they should

81
00:04:01.039 --> 00:04:02.120
<v Speaker 2>feel okay skipping it.

82
00:04:02.199 --> 00:04:04.680
<v Speaker 1>Which puts the pressure on the meeting organizer to make

83
00:04:04.719 --> 00:04:05.479
<v Speaker 1>it worthwhile.

84
00:04:05.919 --> 00:04:09.560
<v Speaker 2>Be focused, prepared, know that people are choosing to spend

85
00:04:09.560 --> 00:04:10.280
<v Speaker 2>their time there.

86
00:04:10.680 --> 00:04:14.639
<v Speaker 1>Now, obviously some meetings you need everyone for team building,

87
00:04:14.719 --> 00:04:15.919
<v Speaker 1>big company updates.

88
00:04:16.040 --> 00:04:19.439
<v Speaker 2>Of course, the guide acknowledges that it's not about eliminating meetings,

89
00:04:19.439 --> 00:04:20.800
<v Speaker 2>but making them more intentional.

90
00:04:20.879 --> 00:04:24.879
<v Speaker 1>Okay, so keeping all this work organized tracking it. The

91
00:04:24.920 --> 00:04:27.759
<v Speaker 1>guide talks quite a bit about getub projects as a

92
00:04:27.879 --> 00:04:28.600
<v Speaker 1>platform for that.

93
00:04:28.759 --> 00:04:31.319
<v Speaker 2>Yeah, it's presented as really adaptable. You can add all

94
00:04:31.319 --> 00:04:34.600
<v Speaker 2>sorts of work items, tasks, bugs, features.

95
00:04:34.160 --> 00:04:36.399
<v Speaker 1>Whatever, and attach metadata.

96
00:04:35.839 --> 00:04:40.240
<v Speaker 2>Exactly status, priority, who's assigned all that stuff? And it

97
00:04:40.360 --> 00:04:43.279
<v Speaker 2>highlights two main views, the table.

98
00:04:43.079 --> 00:04:45.920
<v Speaker 1>View good for data entry sorting right, and the board.

99
00:04:45.759 --> 00:04:48.160
<v Speaker 2>View that visual canban style, drag and drop thing.

100
00:04:48.279 --> 00:04:51.040
<v Speaker 1>Lots of teams love that visual overview is huge for

101
00:04:51.120 --> 00:04:53.680
<v Speaker 1>seeing where things stand, spotting blockers.

102
00:04:53.319 --> 00:04:56.920
<v Speaker 2>Quickly, and the guide mentions the beta version of projects

103
00:04:56.959 --> 00:05:00.120
<v Speaker 2>is where things are headed even more flexible, easier to

104
00:05:00.000 --> 00:05:03.759
<v Speaker 2>to share configurations across teams. That's the future direction and

105
00:05:03.800 --> 00:05:07.399
<v Speaker 2>a core part of planning and tracking. In Geithub issues

106
00:05:07.480 --> 00:05:10.720
<v Speaker 2>Right GitHub issues, the guide explains how they're used for

107
00:05:11.000 --> 00:05:16.199
<v Speaker 2>well everything, tracking tasks, suggesting features, logging bugs, and they're collaborative,

108
00:05:16.360 --> 00:05:21.639
<v Speaker 2>totally full history linked directly to commits, pull requests, even

109
00:05:21.680 --> 00:05:22.800
<v Speaker 2>other related issues.

110
00:05:23.079 --> 00:05:26.759
<v Speaker 1>So issues become the central hub for anything related to

111
00:05:26.800 --> 00:05:29.560
<v Speaker 1>a specific piece of work or problem pretty much.

112
00:05:29.920 --> 00:05:33.480
<v Speaker 2>And there are some neat features like creating hierarchies. Breaking

113
00:05:33.519 --> 00:05:37.920
<v Speaker 2>down big tasks into smaller subtasks makes things more manageable and.

114
00:05:37.879 --> 00:05:39.879
<v Speaker 1>The filtering and sorting powerful.

115
00:05:40.199 --> 00:05:42.639
<v Speaker 2>The guide points out that every filter you apply just

116
00:05:42.680 --> 00:05:45.480
<v Speaker 2>adds text to the search bar, so it's super transparent.

117
00:05:45.839 --> 00:05:49.279
<v Speaker 2>You can quickly see status labels, linked prs.

118
00:05:49.399 --> 00:05:52.920
<v Speaker 1>Everything and for consistency especially with lots of different types

119
00:05:52.959 --> 00:05:56.240
<v Speaker 1>of issues flying around. The guide really pushes issue templates.

120
00:05:56.279 --> 00:05:58.879
<v Speaker 2>Oh, this is smart. You can create templates using markdown

121
00:05:58.959 --> 00:06:02.279
<v Speaker 2>for free form texts, or yammel or yamal for structured forms,

122
00:06:02.439 --> 00:06:05.680
<v Speaker 2>text boxes, drop downs, check boxes. You can even make

123
00:06:05.720 --> 00:06:07.120
<v Speaker 2>fields required.

124
00:06:06.879 --> 00:06:08.720
<v Speaker 1>Ensure as you get all the essential info.

125
00:06:08.600 --> 00:06:13.040
<v Speaker 2>Upfront, right standardizes things mix processing new issues much faster.

126
00:06:13.360 --> 00:06:16.079
<v Speaker 1>Okay, let's zoom out a bit talk about the influence

127
00:06:16.079 --> 00:06:19.240
<v Speaker 1>of open source and this related idea of inner source.

128
00:06:19.480 --> 00:06:20.920
<v Speaker 1>The guide as a whole chapter on this.

129
00:06:21.199 --> 00:06:24.439
<v Speaker 2>Yeah, and it gives some interesting historical context the free

130
00:06:24.480 --> 00:06:27.519
<v Speaker 2>software movement. How open source became the preferred term in

131
00:06:27.519 --> 00:06:28.800
<v Speaker 2>the late nineties, Eric.

132
00:06:28.759 --> 00:06:31.560
<v Speaker 1>Raymond, Bruce Parrins the Open Source Initiative exactly.

133
00:06:31.639 --> 00:06:36.839
<v Speaker 2>Linus Torvalds, creators of Pearl Python, getting those key figures

134
00:06:36.839 --> 00:06:38.680
<v Speaker 2>on board early was huge.

135
00:06:39.120 --> 00:06:42.839
<v Speaker 1>It's amazing how much foundational tech is open source now.

136
00:06:43.480 --> 00:06:45.519
<v Speaker 1>But the guide makes a great point. It's not just

137
00:06:45.560 --> 00:06:47.480
<v Speaker 1>about using open source code, No, it's.

138
00:06:47.319 --> 00:06:50.839
<v Speaker 2>About learning from how those successful open source projects work,

139
00:06:50.920 --> 00:06:52.480
<v Speaker 2>the collaboration models.

140
00:06:52.160 --> 00:06:54.079
<v Speaker 1>And applying those principles inside your own company.

141
00:06:54.160 --> 00:06:57.079
<v Speaker 2>That's inner source. Yeah, it can really boost collaboration between

142
00:06:57.160 --> 00:06:59.360
<v Speaker 2>internal teams help share knowledge, but.

143
00:06:59.319 --> 00:07:02.920
<v Speaker 1>The guide is bound, so it warns about risks too, right, license.

144
00:07:02.600 --> 00:07:06.160
<v Speaker 2>Compliance big one, and understanding that if an open source

145
00:07:06.160 --> 00:07:09.600
<v Speaker 2>component has a bug or vulnerability, well that's now potentially

146
00:07:09.600 --> 00:07:12.199
<v Speaker 2>your problem too. Managing dependencies is.

147
00:07:12.120 --> 00:07:15.480
<v Speaker 1>Critical, which leads to that strategic decision. Yeah, build it

148
00:07:15.519 --> 00:07:19.240
<v Speaker 1>yourself insourcing or use external stuff outsourcing?

149
00:07:19.480 --> 00:07:22.439
<v Speaker 2>Yeah, the guide suggests you really need to think is

150
00:07:22.480 --> 00:07:25.319
<v Speaker 2>this software core to our business? Does it give us

151
00:07:25.360 --> 00:07:29.079
<v Speaker 2>a competitive edge? If it is generally? Build it internally,

152
00:07:29.199 --> 00:07:32.360
<v Speaker 2>maybe some cosourcing, but own that expertise long.

153
00:07:32.319 --> 00:07:34.600
<v Speaker 1>Term makes sense. You don't outsource your secret sauce.

154
00:07:35.160 --> 00:07:38.560
<v Speaker 2>But for non core stuff, outsourcing or leveraging good open

155
00:07:38.560 --> 00:07:42.160
<v Speaker 2>source solutions can be smarter, less risk than being the

156
00:07:42.160 --> 00:07:45.439
<v Speaker 2>only customer for something niche, potentially better quality from a

157
00:07:45.439 --> 00:07:46.879
<v Speaker 2>wider community.

158
00:07:46.920 --> 00:07:49.519
<v Speaker 1>And connecting to all. This is getub sponsors.

159
00:07:49.160 --> 00:07:53.360
<v Speaker 2>Right, a direct way for companies, even individuals to financially

160
00:07:53.399 --> 00:07:56.600
<v Speaker 2>support the maintainers of open source projects they depend.

161
00:07:56.319 --> 00:08:00.879
<v Speaker 1>On giving back helping keep those projects sustainable. Okay, let's

162
00:08:00.879 --> 00:08:04.720
<v Speaker 1>pivot to a core DevOps practice automation with GitHub actions.

163
00:08:04.720 --> 00:08:05.439
<v Speaker 1>Big section on this.

164
00:08:05.639 --> 00:08:08.439
<v Speaker 2>Yeah, this is where we really start talking about accelerating

165
00:08:08.480 --> 00:08:12.639
<v Speaker 2>the delivery pipeline. The guide breaks down the basics. Workflows

166
00:08:12.759 --> 00:08:14.120
<v Speaker 2>are your automated processes.

167
00:08:14.120 --> 00:08:15.319
<v Speaker 1>Pipelines are the stages.

168
00:08:15.720 --> 00:08:19.439
<v Speaker 2>Actions are the individual steps, and it introduces YAML, the

169
00:08:19.519 --> 00:08:20.959
<v Speaker 2>language you use to define.

170
00:08:20.680 --> 00:08:24.399
<v Speaker 1>All this YAML. That indentation can look a bit scary

171
00:08:24.439 --> 00:08:24.959
<v Speaker 1>at first.

172
00:08:24.839 --> 00:08:28.680
<v Speaker 2>You can, but the guide explains the basics pretty well, comments,

173
00:08:28.800 --> 00:08:31.639
<v Speaker 2>data types, how lists and dictionaries work. It helps get

174
00:08:31.639 --> 00:08:35.200
<v Speaker 2>you started. Then it moves into defining a workflow, giving

175
00:08:35.279 --> 00:08:37.240
<v Speaker 2>it a name, setting up the triggers.

176
00:08:37.480 --> 00:08:40.080
<v Speaker 1>The triggers the events that kick off the workflow.

177
00:08:39.799 --> 00:08:42.840
<v Speaker 2>Exactly and they're super flexible. Run on a push to

178
00:08:42.879 --> 00:08:45.840
<v Speaker 2>a specific branch like main or release branches, or when

179
00:08:45.879 --> 00:08:48.639
<v Speaker 2>a pull request is opened, or as signed or labeled,

180
00:08:48.759 --> 00:08:51.600
<v Speaker 2>even on a schedule. Lots of control over when things

181
00:08:51.679 --> 00:08:52.559
<v Speaker 2>run automatically.

182
00:08:52.919 --> 00:08:58.639
<v Speaker 1>Now automation, especially deployments, you need to handle secrets securely. Yeah,

183
00:08:58.679 --> 00:08:59.840
<v Speaker 1>API keys.

184
00:08:59.720 --> 00:09:05.279
<v Speaker 2>Path absolutely critical. The guide emphasizes this. GitHub provides secure

185
00:09:05.360 --> 00:09:09.000
<v Speaker 2>storage for secrets at the repository level ORG level, even

186
00:09:09.039 --> 00:09:10.720
<v Speaker 2>for specific deployment environments.

187
00:09:10.799 --> 00:09:12.200
<v Speaker 1>Encrypted never shown in logs.

188
00:09:12.320 --> 00:09:14.960
<v Speaker 2>Right at the org level, you can control which repos

189
00:09:15.000 --> 00:09:17.960
<v Speaker 2>can access which secrets. For environment secrets, you can even

190
00:09:18.000 --> 00:09:22.320
<v Speaker 2>require manual approval before a workflow uses them extra security.

191
00:09:21.840 --> 00:09:24.639
<v Speaker 1>Layer, and you can manage secrets via the CLI too

192
00:09:24.720 --> 00:09:25.919
<v Speaker 1>for scripting m HM.

193
00:09:25.919 --> 00:09:28.639
<v Speaker 2>The guide mentions that, and it clearly shows how to

194
00:09:28.679 --> 00:09:31.879
<v Speaker 2>use secrets in your workflow, using the secrets context, passing

195
00:09:31.960 --> 00:09:34.840
<v Speaker 2>them as inputs to actions, or as environment variables.

196
00:09:34.840 --> 00:09:37.080
<v Speaker 1>What about building your own actions, not just using ones

197
00:09:37.120 --> 00:09:37.879
<v Speaker 1>from the marketplace.

198
00:09:38.039 --> 00:09:41.440
<v Speaker 2>The guide covers that too. Walk through an example. Define

199
00:09:41.480 --> 00:09:46.279
<v Speaker 2>an action dot AML file describing inputs, outputs, how it runs, and.

200
00:09:46.279 --> 00:09:49.759
<v Speaker 1>An entry point dot S script with the actual commands exactly.

201
00:09:49.799 --> 00:09:53.200
<v Speaker 2>You define what inputs your action needs, what outputs it produces.

202
00:09:53.600 --> 00:09:54.960
<v Speaker 2>It's pretty powerful and.

203
00:09:54.879 --> 00:09:56.720
<v Speaker 1>If you build something cool, you can share it on

204
00:09:56.759 --> 00:09:57.360
<v Speaker 1>the marketplace.

205
00:09:57.480 --> 00:10:00.559
<v Speaker 2>Yep, publish it, let others use it. Builds that whole

206
00:10:00.600 --> 00:10:02.919
<v Speaker 2>ecosystem of reusable automation components.

207
00:10:03.000 --> 00:10:06.960
<v Speaker 1>Okay, last bit on actions. Where do these workflows actually run?

208
00:10:07.639 --> 00:10:09.399
<v Speaker 1>Hosted versus self hosted runners?

209
00:10:09.559 --> 00:10:15.399
<v Speaker 2>Right? GitHub hosted runners are vms managed by GitHub, Linux, Windows, macohsts.

210
00:10:15.840 --> 00:10:18.519
<v Speaker 2>Each job runs in a fresh, isolated environment.

211
00:10:18.679 --> 00:10:22.240
<v Speaker 1>Isolation sounds good for security and you get admin privileges.

212
00:10:22.480 --> 00:10:25.799
<v Speaker 2>That's surprising, it is, But the downside can be build times.

213
00:10:25.799 --> 00:10:28.759
<v Speaker 2>If you need lots of tools installed each run and cost.

214
00:10:29.080 --> 00:10:30.000
<v Speaker 1>How does cost work?

215
00:10:30.159 --> 00:10:33.720
<v Speaker 2>Free for public repos Mostly private repos get an allocation

216
00:10:33.799 --> 00:10:37.000
<v Speaker 2>of minutes and storage with your plan go over you might.

217
00:10:36.919 --> 00:10:38.440
<v Speaker 1>Pay extra and self hosted.

218
00:10:38.639 --> 00:10:41.960
<v Speaker 2>You provide the infrastructure. You manage. The machines might be

219
00:10:42.000 --> 00:10:46.200
<v Speaker 2>necessary for specific network rules like ip alo lists. More control,

220
00:10:46.320 --> 00:10:48.120
<v Speaker 2>but more management overhead.

221
00:10:48.200 --> 00:10:52.120
<v Speaker 1>Okay. Automated builds are sorted. Now managing the packages. The

222
00:10:52.159 --> 00:10:54.600
<v Speaker 1>dependencies getub packages.

223
00:10:54.840 --> 00:10:58.360
<v Speaker 2>This is about managing dependencies in a structured way. The

224
00:10:58.440 --> 00:11:02.879
<v Speaker 2>guide mentions popular register NPM for JavaScript, Docker for containers,

225
00:11:03.039 --> 00:11:04.519
<v Speaker 2>nugit for dot net, and.

226
00:11:04.440 --> 00:11:06.720
<v Speaker 1>You can integrate these with GitHub actions roamlessly.

227
00:11:07.080 --> 00:11:10.240
<v Speaker 2>You can automate the whole release process. Build succeeds dot

228
00:11:10.360 --> 00:11:12.480
<v Speaker 2>BA back publish to the registry.

229
00:11:11.960 --> 00:11:15.440
<v Speaker 1>And using semantic versioning major minor patches. Yeah.

230
00:11:15.440 --> 00:11:19.039
<v Speaker 2>The guide stresses using simber and automating the versioning with actions.

231
00:11:19.360 --> 00:11:22.960
<v Speaker 2>Trigger a workflow on a new GitHub release. It automatically

232
00:11:22.960 --> 00:11:26.039
<v Speaker 2>bumps the version using tools like NPM version or git version,

233
00:11:26.279 --> 00:11:29.559
<v Speaker 2>then publishes the package. Streamlines everything fewer errors.

234
00:11:29.679 --> 00:11:32.919
<v Speaker 1>For container images, it mentions the git ub container registry,

235
00:11:33.320 --> 00:11:35.399
<v Speaker 1>GHCR dot io.

236
00:11:35.399 --> 00:11:38.919
<v Speaker 2>Right images can be owned by ords or users, fine

237
00:11:38.960 --> 00:11:40.039
<v Speaker 2>grained access.

238
00:11:39.679 --> 00:11:42.000
<v Speaker 1>Control, and again automate it with actions.

239
00:11:42.080 --> 00:11:44.960
<v Speaker 2>Build the docker image, log in securely using the jit

240
00:11:45.039 --> 00:11:48.360
<v Speaker 2>hub token, push the image. It makes sharing code as

241
00:11:48.399 --> 00:11:52.120
<v Speaker 2>containers or versioned packages much much smoother solves a lot

242
00:11:52.159 --> 00:11:53.000
<v Speaker 2>of release headaches.

243
00:11:53.159 --> 00:12:00.600
<v Speaker 1>Okay, codes packaged now, deployment infrastructure as code iac and automation.

244
00:12:00.200 --> 00:12:04.840
<v Speaker 2>There super fundamental and modern DevOps IC means managing your

245
00:12:04.879 --> 00:12:10.120
<v Speaker 2>infrastructure servers, networks, databases using code, not manual clicks. The

246
00:12:10.200 --> 00:12:14.720
<v Speaker 2>guide lists the big tools Terraform, polumy, Ancable, chef Puppet.

247
00:12:15.000 --> 00:12:17.039
<v Speaker 1>It makes a point though, just because a tool supports

248
00:12:17.080 --> 00:12:20.559
<v Speaker 1>multiple clouds doesn't mean your exact config works everywhere without changes.

249
00:12:20.639 --> 00:12:21.159
<v Speaker 1>Right correct.

250
00:12:21.159 --> 00:12:23.480
<v Speaker 2>You'll still need some cloud specific bits, but the core

251
00:12:23.559 --> 00:12:26.879
<v Speaker 2>benefit is consistency, repeatability in managing infrastructure.

252
00:12:27.000 --> 00:12:29.360
<v Speaker 1>How do team structure deployment responsibility?

253
00:12:29.440 --> 00:12:32.480
<v Speaker 2>The guide mentions a few models centralized where an OPS

254
00:12:32.480 --> 00:12:36.600
<v Speaker 2>team handles everything, Decentralized where feature teams deploy their own services,

255
00:12:36.639 --> 00:12:38.840
<v Speaker 2>more and template.

256
00:12:38.360 --> 00:12:40.840
<v Speaker 1>It, where a central team provides templates.

257
00:12:40.600 --> 00:12:44.519
<v Speaker 2>Exactly feature teams use and customize them. Good balance between

258
00:12:44.519 --> 00:12:46.960
<v Speaker 2>consistency and flexibility.

259
00:12:46.320 --> 00:12:48.639
<v Speaker 1>And reusable workflows and actions help here too.

260
00:12:48.639 --> 00:12:51.080
<v Speaker 2>Definitely enhance consistency, efficiency, and.

261
00:12:51.039 --> 00:12:54.600
<v Speaker 1>Deployment and measuring success. Back to the four keys.

262
00:12:54.919 --> 00:12:59.000
<v Speaker 2>Yep, the Dora metrics deployment frequency, lead time for changes,

263
00:12:59.159 --> 00:13:02.919
<v Speaker 2>meantime to restore or change fail rate if you're auto deploying.

264
00:13:03.159 --> 00:13:07.919
<v Speaker 2>The guide says, move beyond surveys track these real world metrics.

265
00:13:08.000 --> 00:13:13.720
<v Speaker 1>Okay, shifting gears, managing feature rollouts, feature flags or toggles.

266
00:13:13.480 --> 00:13:17.159
<v Speaker 2>Super powerful technique. Deploy new code to production, but keep

267
00:13:17.159 --> 00:13:18.200
<v Speaker 2>the feature turned.

268
00:13:17.919 --> 00:13:19.879
<v Speaker 1>Off initially, then rolled out gradually.

269
00:13:20.159 --> 00:13:24.840
<v Speaker 2>Yeah. The guide outlines a typical life cycle ideation, internal testing, alpha,

270
00:13:24.919 --> 00:13:28.440
<v Speaker 2>beta with small external groups, then maybe a preview release

271
00:13:28.480 --> 00:13:30.120
<v Speaker 2>eventually default for everyone.

272
00:13:30.240 --> 00:13:34.039
<v Speaker 1>Advantages seem clear. Merge code more often, zero downtime deployments

273
00:13:34.080 --> 00:13:35.759
<v Speaker 1>by hiding unfinished stuff.

274
00:13:35.600 --> 00:13:39.639
<v Speaker 2>Much more control over the rollout. But beware feature flag.

275
00:13:39.360 --> 00:13:42.519
<v Speaker 1>Hell ah, yes, too many flags. Nobody knows what they.

276
00:13:42.360 --> 00:13:46.879
<v Speaker 2>Do exactly, so best practices track metrics on flag usage,

277
00:13:46.879 --> 00:13:51.240
<v Speaker 2>have central management with clear ownership, document dependencies between flags,

278
00:13:51.399 --> 00:13:52.440
<v Speaker 2>keep it tidy.

279
00:13:52.320 --> 00:13:55.039
<v Speaker 1>And flags aren't just for releases, but for experiments too.

280
00:13:55.440 --> 00:13:56.240
<v Speaker 1>Ab testing.

281
00:13:56.320 --> 00:14:00.480
<v Speaker 2>Absolutely formulate a hypothesis this new feature will improve conversion

282
00:14:00.480 --> 00:14:03.399
<v Speaker 2>by x percent. Use a flag to show it to

283
00:14:03.440 --> 00:14:06.399
<v Speaker 2>say ten percent of users compare their behavior to the

284
00:14:06.399 --> 00:14:08.000
<v Speaker 2>control group ninety percent.

285
00:14:08.240 --> 00:14:13.240
<v Speaker 1>Gather data, validate or invalidate your idea objective measurement exactly.

286
00:14:13.360 --> 00:14:16.159
<v Speaker 2>The guide even has an example with a simplified registration

287
00:14:16.240 --> 00:14:17.120
<v Speaker 2>dialogue Test.

288
00:14:16.919 --> 00:14:21.600
<v Speaker 1>Okay, different topic. Managing code branches trunk based development, faster velocity.

289
00:14:21.840 --> 00:14:26.279
<v Speaker 2>That's the claim The core idea very few long lived branches.

290
00:14:26.320 --> 00:14:29.679
<v Speaker 2>Ideally age is one main trunk feature branches, keep them

291
00:14:29.679 --> 00:14:31.600
<v Speaker 2>super short lived, merge back daily.

292
00:14:31.639 --> 00:14:34.200
<v Speaker 1>Ideally it's more model than a strict workflow.

293
00:14:33.919 --> 00:14:36.879
<v Speaker 2>Right adopted by many high performing teams. The guide talks

294
00:14:36.879 --> 00:14:40.279
<v Speaker 2>about GitHub flow and variations like myflow as examples.

295
00:14:40.399 --> 00:14:43.799
<v Speaker 1>What's the issue with pure GitHub flow? Sometimes deploying every

296
00:14:43.840 --> 00:14:44.639
<v Speaker 1>pr straight.

297
00:14:44.480 --> 00:14:47.960
<v Speaker 2>To prod can become a bottleneck, So a pragmatic adaptation

298
00:14:48.840 --> 00:14:52.240
<v Speaker 2>validate prs in a test environment but only deploy to

299
00:14:52.320 --> 00:14:54.600
<v Speaker 2>prod after merging to the trunk makes sense.

300
00:14:55.120 --> 00:15:01.840
<v Speaker 1>And with short branches frequent merges, code integration is key, urging, rebasing.

301
00:15:01.440 --> 00:15:05.559
<v Speaker 2>Dealing with conflicts. The guide covers techniques also handling hot

302
00:15:05.600 --> 00:15:07.840
<v Speaker 2>fixes for old releases using cherry pick.

303
00:15:07.919 --> 00:15:11.279
<v Speaker 1>It even has that cool get alias example amstart.

304
00:15:10.840 --> 00:15:15.399
<v Speaker 2>Yeah in their miflow strategy automates creating a branch, committing changes, pushing,

305
00:15:15.639 --> 00:15:18.279
<v Speaker 2>creating a draft pr nice little workflow helper.

306
00:15:18.360 --> 00:15:22.639
<v Speaker 1>Now ensuring quality in this fast pace. Yeah, shift left

307
00:15:22.639 --> 00:15:24.440
<v Speaker 1>testing testing earlier.

308
00:15:24.120 --> 00:15:27.279
<v Speaker 2>Crucial, The guide argues, manual testing just doesn't scale anymore.

309
00:15:27.559 --> 00:15:30.960
<v Speaker 2>You need robust, automated tests, owned and maintained by the

310
00:15:30.960 --> 00:15:31.879
<v Speaker 2>dev team itself.

311
00:15:31.919 --> 00:15:32.960
<v Speaker 1>Why own by devs?

312
00:15:33.080 --> 00:15:35.639
<v Speaker 2>If developers test their own code, they tend to write

313
00:15:35.639 --> 00:15:36.960
<v Speaker 2>more testable code to begin with.

314
00:15:37.159 --> 00:15:39.759
<v Speaker 1>Uh makes sense, So shift left principles.

315
00:15:39.840 --> 00:15:42.879
<v Speaker 2>Test at the lowest level possible. Unit tests first, right

316
00:15:42.960 --> 00:15:46.360
<v Speaker 2>tests once run everywhere. Treat test code like production code.

317
00:15:46.440 --> 00:15:48.440
<v Speaker 2>Keep it clean and the core you code it, you

318
00:15:48.480 --> 00:15:50.360
<v Speaker 2>test it. Develop a responsibility.

319
00:15:50.399 --> 00:15:53.759
<v Speaker 1>It mentions a testing manifesto QA roll evolving.

320
00:15:54.120 --> 00:15:56.559
<v Speaker 2>Yeah, QA isn't just finding bugs at the end. It's

321
00:15:56.600 --> 00:15:59.639
<v Speaker 2>about building quality in throughout the process. And then it

322
00:15:59.679 --> 00:16:01.919
<v Speaker 2>dives in to TDD test driven development.

323
00:16:02.159 --> 00:16:04.559
<v Speaker 1>Write the test before the code right the.

324
00:16:04.639 --> 00:16:08.879
<v Speaker 2>Red green refactor cycle. Write a failing test, read write

325
00:16:08.879 --> 00:16:11.519
<v Speaker 2>the minimum code to make it past green, then clean

326
00:16:11.559 --> 00:16:15.639
<v Speaker 2>up the code. Refactor leads to better design, less debugging later.

327
00:16:15.919 --> 00:16:20.519
<v Speaker 1>Then manage the whole test portfolio, unit integration end to end.

328
00:16:20.879 --> 00:16:23.679
<v Speaker 2>Know the difference, use them appropriately The guide lays out

329
00:16:23.679 --> 00:16:24.720
<v Speaker 2>their characteristics and.

330
00:16:24.720 --> 00:16:30.320
<v Speaker 1>Then things like fault injection, chaos engineering, proactively breaking stuff.

331
00:16:30.519 --> 00:16:34.679
<v Speaker 2>Sounds scary, but it's about testing resilience. Introduce failures in

332
00:16:34.720 --> 00:16:38.159
<v Speaker 2>production controlled to see how a system handles it. Verify

333
00:16:38.200 --> 00:16:39.879
<v Speaker 2>your safeguard's work builds really.

334
00:16:39.799 --> 00:16:44.159
<v Speaker 1>Robust systems igh stakes, and finally, test management in GitHub

335
00:16:44.639 --> 00:16:45.799
<v Speaker 1>tools for tracking results.

336
00:16:45.840 --> 00:16:47.759
<v Speaker 2>Yeah, integrating test results into the workflow.

337
00:16:47.840 --> 00:16:53.519
<v Speaker 1>Okay. Another shift left security devsekops. Integrating security throughout not

338
00:16:53.600 --> 00:16:54.360
<v Speaker 1>an afterthought.

339
00:16:54.559 --> 00:16:58.039
<v Speaker 2>Starts with the assumer reach mindset and zero trust principles.

340
00:16:58.279 --> 00:17:01.480
<v Speaker 2>Don't assume your internal network is safe, assume a breach

341
00:17:01.519 --> 00:17:05.839
<v Speaker 2>could happen anywhere. Focus shifts to detection, response.

342
00:17:05.400 --> 00:17:09.319
<v Speaker 1>Recovery, and prepping for that with attack simulations Red Team,

343
00:17:09.359 --> 00:17:09.960
<v Speaker 1>Blue Tank.

344
00:17:09.920 --> 00:17:15.839
<v Speaker 2>Exactly, Red Team attacks simulated, ethical, Blue Team defends, identify weaknesses,

345
00:17:15.960 --> 00:17:19.799
<v Speaker 2>raise awareness, train response teams. The guide has ground rules

346
00:17:19.839 --> 00:17:21.519
<v Speaker 2>for doing this safely and productively.

347
00:17:21.799 --> 00:17:23.119
<v Speaker 1>Common attacks to watch for.

348
00:17:23.240 --> 00:17:28.839
<v Speaker 2>Phishing, unprotected resources left open, exploiting compromised machines, spear phishing too.

349
00:17:28.960 --> 00:17:30.119
<v Speaker 2>The targeted kind and.

350
00:17:30.079 --> 00:17:32.799
<v Speaker 1>Gidthub code spaces is a more secure dev environment.

351
00:17:32.960 --> 00:17:35.720
<v Speaker 2>Yeah, hosting the whole workspace in the cloud reduces the

352
00:17:35.720 --> 00:17:37.839
<v Speaker 2>attack surface on local machines.

353
00:17:37.559 --> 00:17:41.279
<v Speaker 1>Makes sense now. Securing the code itself, getub features.

354
00:17:40.880 --> 00:17:45.079
<v Speaker 2>For this DependaBot is huge automatically checks dependencies for vulnerabilities,

355
00:17:45.119 --> 00:17:50.279
<v Speaker 2>creates prs with updates, supports tons of ecosystems, set it daily, weekly, monthly,

356
00:17:50.559 --> 00:17:51.559
<v Speaker 2>keeps things patched.

357
00:17:51.680 --> 00:17:55.960
<v Speaker 1>Huge timesaver prevents known vulns creeping in and secret scanning.

358
00:17:56.039 --> 00:17:58.759
<v Speaker 2>YEP scans public, repos and private if you have advanced

359
00:17:58.759 --> 00:18:04.359
<v Speaker 2>security for accidentally committed secrets, API keys, tokens, oops.

360
00:18:03.720 --> 00:18:06.599
<v Speaker 1>And code QL for deeper static analysis.

361
00:18:06.160 --> 00:18:09.680
<v Speaker 2>Right set it up in actions scans code for security issues,

362
00:18:09.799 --> 00:18:12.960
<v Speaker 2>quality problems without running it. Results show up right in

363
00:18:13.000 --> 00:18:14.160
<v Speaker 2>the pull request.

364
00:18:13.799 --> 00:18:17.279
<v Speaker 1>That PR integration is gold, catch issues before merging.

365
00:18:17.079 --> 00:18:19.839
<v Speaker 2>Totally, and you can write custom co QL queries for

366
00:18:19.880 --> 00:18:21.279
<v Speaker 2>specific patterns you care about.

367
00:18:21.359 --> 00:18:27.160
<v Speaker 1>Okay, beyond the code securing deployments, container scanning, infrastructure scanning,

368
00:18:27.160 --> 00:18:28.039
<v Speaker 1>you need to check those two.

369
00:18:28.240 --> 00:18:31.720
<v Speaker 2>The guide mentions tools like anchor Claire for containers have

370
00:18:31.880 --> 00:18:35.480
<v Speaker 2>infrastructure policies. Audit configus regularly.

371
00:18:35.000 --> 00:18:37.880
<v Speaker 1>And automated infrachanges with ic managed via.

372
00:18:37.759 --> 00:18:41.519
<v Speaker 2>PRS provides that audit trail control. The guide brings up

373
00:18:41.519 --> 00:18:43.160
<v Speaker 2>the solar winds attack as a reminder.

374
00:18:43.200 --> 00:18:45.960
<v Speaker 1>Supply chain security critical.

375
00:18:45.559 --> 00:18:49.640
<v Speaker 2>Which leads to things like s BOM software bill of materials,

376
00:18:49.799 --> 00:18:50.799
<v Speaker 2>what's in your software?

377
00:18:50.920 --> 00:18:53.920
<v Speaker 1>Commit signing, verifying the author code.

378
00:18:53.759 --> 00:18:57.200
<v Speaker 2>Signing, verifying the release integrity? All important pieces.

379
00:18:57.240 --> 00:18:58.359
<v Speaker 1>What about active testing?

380
00:19:00.079 --> 00:19:04.319
<v Speaker 2>Dynamic application security testing? Test the running application? O wasp

381
00:19:04.440 --> 00:19:06.200
<v Speaker 2>z app is a popular open source.

382
00:19:05.960 --> 00:19:08.640
<v Speaker 1>Tool for this and generally harden the whole release pipeline,

383
00:19:08.720 --> 00:19:11.839
<v Speaker 1>secure runners, lease privilege monitoring.

384
00:19:11.400 --> 00:19:15.200
<v Speaker 2>The whole nine yards. Security needs to be baked in everywhere, and.

385
00:19:15.119 --> 00:19:17.720
<v Speaker 1>The guide circles back to E shaped team members.

386
00:19:17.880 --> 00:19:22.240
<v Speaker 2>Yeah, people with broad experience, deep expertise, curiosity for exploration

387
00:19:22.359 --> 00:19:26.720
<v Speaker 2>and strong execution skills need that mix for high collaboration

388
00:19:26.920 --> 00:19:28.640
<v Speaker 2>across all these areas.

389
00:19:29.079 --> 00:19:31.039
<v Speaker 1>So how do we measure if all this is working?

390
00:19:31.400 --> 00:19:35.279
<v Speaker 1>Metrics that matter engineering velocity, developer productivity.

391
00:19:35.559 --> 00:19:39.079
<v Speaker 2>The guide starts with the why why accelerate companies life

392
00:19:39.079 --> 00:19:43.440
<v Speaker 2>spans are shrinking. Digital capabilities are crucial for survival. IT

393
00:19:43.519 --> 00:19:46.119
<v Speaker 2>mentions the McKinsey Developer Velocity Index.

394
00:19:45.880 --> 00:19:48.920
<v Speaker 1>DVII HIDVII companies outperform significantly.

395
00:19:49.000 --> 00:19:52.400
<v Speaker 2>Yes, So how to measure back to the four keys

396
00:19:52.640 --> 00:19:56.519
<v Speaker 2>deployment frequency, lead time for changes, MTTR, change fail rate,

397
00:19:57.000 --> 00:19:59.240
<v Speaker 2>use surveys initially if you have to, but aim for

398
00:19:59.359 --> 00:20:00.200
<v Speaker 2>direct measure.

399
00:20:00.400 --> 00:20:03.519
<v Speaker 1>But productivity is broader than just those four, much broader.

400
00:20:03.759 --> 00:20:08.440
<v Speaker 2>The guide introduces the space framework satisfaction and well being, performance, activity,

401
00:20:08.440 --> 00:20:12.640
<v Speaker 2>communication and collaboration, efficiency and flow, need a balanced view.

402
00:20:12.680 --> 00:20:14.680
<v Speaker 1>And OKRs objectives and key.

403
00:20:14.519 --> 00:20:18.240
<v Speaker 2>Results to align engineering work with business goals, track progress,

404
00:20:18.319 --> 00:20:19.599
<v Speaker 2>prioritize effectively.

405
00:20:20.000 --> 00:20:23.039
<v Speaker 1>The guide then quickly revisits some earlier topics in light

406
00:20:23.079 --> 00:20:24.480
<v Speaker 1>of metrics.

407
00:20:24.079 --> 00:20:28.880
<v Speaker 2>Right planning and tracking with visual boards, WIP limits, reducing context.

408
00:20:28.480 --> 00:20:30.799
<v Speaker 1>Switching, prioritization, swim lanes.

409
00:20:30.559 --> 00:20:37.640
<v Speaker 2>Trunk based development, myflow, automation, streamlining things, force push considerations.

410
00:20:36.799 --> 00:20:40.440
<v Speaker 1>Shift left testings impact on velocity, the evolving QA role.

411
00:20:40.400 --> 00:20:44.319
<v Speaker 2>Shift left, security again, red blue teams as learning opportunities,

412
00:20:44.559 --> 00:20:46.200
<v Speaker 2>code spaces for secure.

413
00:20:45.880 --> 00:20:49.839
<v Speaker 1>Dev and linking metrics back to business goals. Developer satisfaction

414
00:20:49.960 --> 00:20:51.559
<v Speaker 1>is key to absolutely happy.

415
00:20:51.640 --> 00:20:54.359
<v Speaker 2>Effective engineers are productive engineers.

416
00:20:53.880 --> 00:20:58.039
<v Speaker 1>Now making sure we're building the right things, lean product development, lean.

417
00:20:57.920 --> 00:21:03.680
<v Speaker 2>Startup yes, using customer feedback, experimentation, build stuff people actually.

418
00:21:03.319 --> 00:21:05.359
<v Speaker 1>Need and want the build measure, learn.

419
00:21:05.279 --> 00:21:09.279
<v Speaker 2>Loop core concept, build an MVP, quickly, measure how users react,

420
00:21:09.359 --> 00:21:13.680
<v Speaker 2>learn from it, iterate requires understanding your product, your market.

421
00:21:13.839 --> 00:21:16.279
<v Speaker 1>Business acumen for engineers increasingly important.

422
00:21:16.680 --> 00:21:19.240
<v Speaker 2>The guide suggests the business model Canvas as a tool

423
00:21:19.319 --> 00:21:21.319
<v Speaker 2>for engineers to get better at product thinking.

424
00:21:21.599 --> 00:21:25.839
<v Speaker 1>Understanding the product life cycle too, innovators, early adopters.

425
00:21:25.599 --> 00:21:29.799
<v Speaker 2>Majority laggards. Knowing where your product fits helps guide strategy

426
00:21:29.960 --> 00:21:30.799
<v Speaker 2>and experimentation.

427
00:21:30.880 --> 00:21:33.519
<v Speaker 1>Again ab testing for continuous.

428
00:21:33.000 --> 00:21:37.839
<v Speaker 2>Improvement, applying the scientific method, clear hypothesis, design and experiment,

429
00:21:38.359 --> 00:21:43.759
<v Speaker 2>define independent, independent variables, use control groups, rigorous testing tools.

430
00:21:43.759 --> 00:21:48.160
<v Speaker 2>For this mentions growth book Flagger as engineering focused options

431
00:21:48.200 --> 00:21:51.319
<v Speaker 2>and again aligns with okr's experiments. Should help you learn

432
00:21:51.359 --> 00:21:52.480
<v Speaker 2>and achieve your goals.

433
00:21:52.759 --> 00:21:57.920
<v Speaker 1>Okay. Wrapping up with GitHub for bigger organizations, teams and enterprises.

434
00:21:57.440 --> 00:22:02.200
<v Speaker 2>Covers the pricing tiers. Free Team Enterprise highlights enterprise security

435
00:22:02.200 --> 00:22:05.519
<v Speaker 2>features like sam LSSO enterprise managed Users.

436
00:22:05.359 --> 00:22:07.400
<v Speaker 1>EMU, organizing teams within.

437
00:22:07.279 --> 00:22:12.519
<v Speaker 2>GitHub, horizontal vertical, nested teams, visible versus secret teams, managing

438
00:22:12.599 --> 00:22:14.640
<v Speaker 2>access for outside collaborators too.

439
00:22:14.720 --> 00:22:16.279
<v Speaker 1>What about migrating to GitHub?

440
00:22:16.400 --> 00:22:20.279
<v Speaker 2>Discuss the strategies high fidelity, keep all history versus clean cutovers,

441
00:22:20.319 --> 00:22:25.119
<v Speaker 2>start fresh mentions tools, GitHub Enterprise Importer, GEI Valet for

442
00:22:25.240 --> 00:22:28.720
<v Speaker 2>azured DevOps, migration, branching, model changes might be needed if

443
00:22:28.759 --> 00:22:29.720
<v Speaker 2>coming from something else.

444
00:22:29.920 --> 00:22:33.119
<v Speaker 1>And finally, why do so many big transformations fail?

445
00:22:33.359 --> 00:22:36.680
<v Speaker 2>Critical question? The guide points to lack of clear vision,

446
00:22:36.880 --> 00:22:42.319
<v Speaker 2>not enough coaching, unsupportive culture, shares principles for success, ask forgiveness,

447
00:22:42.960 --> 00:22:46.920
<v Speaker 2>You build it, you run it, fail early, embrace failure, collaborate,

448
00:22:47.079 --> 00:22:50.920
<v Speaker 2>go fix, Treat servers like cattle. If it hurts, do

449
00:22:51.000 --> 00:22:55.720
<v Speaker 2>it more often. Familiar classic DevOps wisdom, and be data driven,

450
00:22:56.440 --> 00:23:00.160
<v Speaker 2>measure fine bottlenecks, focus improvements there, which brings.

451
00:23:00.119 --> 00:23:02.119
<v Speaker 1>Us back to DevOps culture itself.

452
00:23:02.240 --> 00:23:07.240
<v Speaker 2>The union of people, process products, built on learning, collaboration, ownership,

453
00:23:07.240 --> 00:23:08.039
<v Speaker 2>that's the foundation.

454
00:23:08.319 --> 00:23:11.319
<v Speaker 1>Wow, okay, we have covered a ton of ground here.

455
00:23:11.359 --> 00:23:14.640
<v Speaker 2>We really have, from the nitty gritty of pull requests.

456
00:23:14.079 --> 00:23:17.640
<v Speaker 1>And automation all the way up to security, integration, metrics,

457
00:23:17.759 --> 00:23:19.160
<v Speaker 1>lean principles, culture.

458
00:23:19.240 --> 00:23:20.440
<v Speaker 2>It's a comprehensive view.

459
00:23:20.559 --> 00:23:22.319
<v Speaker 1>And if there's one thing to really stick in your mind,

460
00:23:22.359 --> 00:23:25.279
<v Speaker 1>remember that stat about company lifespan shrinking.

461
00:23:25.480 --> 00:23:26.799
<v Speaker 2>Yeah, that's a sobering one.

462
00:23:26.839 --> 00:23:29.400
<v Speaker 1>It just hammers home that being able to adapt to

463
00:23:29.440 --> 00:23:33.400
<v Speaker 1>accelerate software delivery it's not a nice to have anymore.

464
00:23:33.759 --> 00:23:35.319
<v Speaker 1>It's survival, it really is.

465
00:23:35.880 --> 00:23:39.319
<v Speaker 2>So we'd encourage you listening to dive deeper into whatever

466
00:23:39.400 --> 00:23:40.880
<v Speaker 2>sparked your interests most today.

467
00:23:41.039 --> 00:23:43.359
<v Speaker 1>Check out the GitHub docs for the tools, look up

468
00:23:43.359 --> 00:23:44.359
<v Speaker 1>those open source.

469
00:23:44.119 --> 00:23:47.920
<v Speaker 2>Projects, and think critically, how could these ideas apply to

470
00:23:48.000 --> 00:23:52.680
<v Speaker 2>your team, your workflow. Maybe identify just one bottleneck, one

471
00:23:52.720 --> 00:23:54.960
<v Speaker 2>small thing you could start improving.

472
00:23:54.759 --> 00:23:59.799
<v Speaker 1>Start small, iterate. So final thought to leave you with go.

473
00:24:00.319 --> 00:24:03.839
<v Speaker 1>Given this relentless pace of change, our total reliance on software,

474
00:24:04.720 --> 00:24:09.559
<v Speaker 1>how will these principles collaboration, automation continues improvement. How will

475
00:24:09.599 --> 00:24:11.920
<v Speaker 1>they change not just software development, but maybe the whole

476
00:24:11.960 --> 00:24:15.480
<v Speaker 1>way organizations operate and deliver value in the future. Think

477
00:24:15.519 --> 00:24:18.599
<v Speaker 1>bigger than just code and deployments. What are the broader implications?

478
00:24:18.680 --> 00:24:20.799
<v Speaker 2>Hm hmm, something that chew on definitely.

479
00:24:21.039 --> 00:24:22.559
<v Speaker 1>Thanks for joining us for this deep dive.