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 <[email protected]> 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" <[email protected]> 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_software_bugs_for_the_Wikipedias > > > > -- > > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | > > | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | > > > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
