1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
|
# Why?
* I realised the following some weeks ago:
I now maintain deployment tooling for one of the most important
websites in the world. When I make a mistake, and Wikipedia goes down,
the whole world will notice.
* How can I avoid making at least some mistakes?
* How can I avoid the New York Times and Hacker News discussing my
shortcomings?
-----------------------------------------------------------------------------
# We have no safe place to...
* Try changes to train tooling
* Try out train tooling to see if it still works
* Learn how to conduct the train
* Experiment with changes to how we do the train
-----------------------------------------------------------------------------
# Theses
* Changing `scap` or `deploy-promote` is plain old software development
* Changing how we do the train is very similar to software development
* We should treat the train as a software development project
-----------------------------------------------------------------------------
# (Controversial?) opinion on development (1/9)
* Agile is not wrong
* Agile is not right
* Same for every other formal method or methodology
* Higher stakes require more formalism
-----------------------------------------------------------------------------
# (Controversial?) opinion on development (2/9)
* Have a rough idea of the end goal
- this will change and become clearer the closer you get
- that's OK, part of the process is figuring out what you (or your
users or customers or stakeholders) really, really want
- don't obsess about getting this exactly right in the beginning
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (3/9)
* Make something that sort of works to start with
- a prototype, spike, wireframe, sketch, whatever
- it can be limited, bad, ugly, and wrong
- a project with a million commits starts with hello, world
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (4/9)
* Iterate quickly, more or less towards the end goal
- have a very clear goal for each iteration
- get feedback at the end of the iteration, to feed into forming
goals for future iterations
- a week is usually enough for one iteration
- many weeks is too long: too much changes in the world in that time
- it's better to spend a week going in the wrong direction than a
month
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (5/9)
* Experiment, make mistakes, learn
- "what happens if I press this button?"
- if nothing bad can happen, just press the button, and then you'll
know
- make sure it's safe to press any button
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (6/9)
* If something is painful, do it more often
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (7/9)
* Smooth away unnecessary friction
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (8/9)
* Acceptance criteria are the most important part of a software project
- knowing what to do is harder than knowing how to do it
- automated tests are more important that production code
-----------------------------------------------------------------------------
# (Controversial?) opinion on software development (9/9)
* It's not finished, until it's run repeatedly
- can your web server handle one billion sequential trivial
read-only requests, however slowly?
- can you conduct the train every week for a year?
-----------------------------------------------------------------------------
# On development speed
* Edit, build, run, test, debug
- the inner loop of software development
- if the loop is slow, development is slow: changes take a long time to make
* Anything that slows down the inner loop is bad
- if the whole world notices when you make a mistake, you are
careful making changes
- the careful developer is a slow developer
* Software development always involves making mistakes
- developing things quickly requires making mistakes fast
- each mistake teaches you something
- but mistakes should be cheap, safe, harmless
-----------------------------------------------------------------------------
# train-dev
* A safe place to make mistakes related to development tooling
* Simulates the production environment sufficiently that if things
work in train-dev, they hopefully work in production
* Does not try to be an exact replica of production
* Will not always be "right", but "sometimes good enough" is vastly
better than "try it in production and take down Wikipedia if
you're wrong"
* We'll make it be closer to production over time
* Iterate, fix discrepancies as we find them
-----------------------------------------------------------------------------
# Overview
* Nested virtual machines
* Outer VM provides an environment in which inner VMs operate in
isolation
* Inner VMs provide the various servers and services needed to conduct
the train
- git server ("Gerrit")
- a deploy server ("deploy1001.eqiad.wmnet")
* The goal is to be able to run all the steps of the train inside the
train-dev environment
-----------------------------------------------------------------------------
# Current status
* The first step works
* `scap prep 1.35.0-wmf.34`
* Real scap, not one modified for train-dev
* Does not access the Internet outside train-dev
* An incomplete, bad, ugly, and wrong first step
* Let's start iterating?
-----------------------------------------------------------------------------
# Do please try this at home!
* train-dev repository on Gerrit
* `vdc/README.md` has instructions
* <https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/train-dev/+/refs/heads/master/vdc/README.md>
* There are pre-built images that you can try, no need to build your
own. But you need to give Lars your SSH public key first so the next
build of the image will give you access the VMs.
-----------------------------------------------------------------------------
# Legalese
Copyright 2020 Wikimedia Foundation
This content is licensed under the Creative Commons
Attribution-ShareAlike 4.0 International ([CC BY-SA 4.0][]) licence.
[CC BY-SA 4.0]: https://creativecommons.org/licenses/by-sa/4.0/
---
title: "Yubikey hardware security tokens"
subtitle: "Lunch and learn"
author: "Lars Wirzenius / Wikimedia Foundation"
date: "2020-09-28"
...
|
