To my understanding this is simply a formalisation of a change that, in almost every regard, already happened months ago.
Dan
On 29 July 2014 11:58, Pine W wiki.pine@gmail.com wrote:
To clarify, is the QA team now under Release Engineering as Chris' comment seems to imply, and how does this org change effect security engineering?
Thanks, Pine On Jul 29, 2014 10:53 AM, "Greg Grossmeier" greg@wikimedia.org wrote:
<quote name="Rob Lanphier" date="2014-07-29" time="09:52:47 -0700"> > They are broadly responsible for the lifecycle of code from the point > that a developer is ready to check it in through its deployment on our > site, maintaining the processes and tools that reduce negative user > impact of site software changes while simultaneously making software > change deployment efficient and joyful.
Chris McMahon shared the below quote on the internal thread for this announcement, and I thought it was useful to share here as well:
<quote name="Chris McMahon" date="2014-07-29" time="08:58:11 -0700"> > I think it's worth pointing out that RelEng is not only concerned with > releasing software early and often, but also concerned with releasing > software *safely*. You don't hear much about it, but stuff we also do: > > * Put in place and run all the linters, unit tests, qunit tests in Jenkins > * Deploy the master branch of all core and all extensions to beta labs > every three minutes > * Run automated browser tests in beta labs at least twice per day, and > analyze the results > * Do exploratory testing in beta labs > * Maintain the deploy tools like scap > * And manage the process within which all of these things are
productive
In Jenkins we find and fix code problems, for example with syntax and structure.
In beta labs we find and fix a number of sorts of problems:
- configuration mistakes, like for caching or database.
- integration problems, for example when a change to VisualEditor makes
it
stop working for MobileFrontend, or a change to Core breaks VE.
- regression problems, where a change in one part of the code
unexpectedly
makes some other features stop working correctly.
People sometimes ask me why the browser test builds are red so much.
The
answer is that they are showing where changes and problems are. Red
tests
give us information.
So today we spend very little time in production "putting out fires",
as
Andrew put it. Of course, we can't find and fix every problem, but I
have
no doubt that our current practices and processes are saving Ops and
Core
and Features engineers many frustrating hours every week.
And speaking of practices and processes, having a Team Practices group
in
place will be great. We have many interests in common.
And if you're interested, I'm giving a short talk on the subject at Wikimania:
https://wikimania2014.wikimedia.org/wiki/Submissions/Finding_and_fixing_soft...
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l