moz_intern_presentation.txt

What am I going to talk about.


First things first, express what I did in one sentence

moving towards Mozharness...

[road image]

Summary of what I did: 'In release engineering, port desktop unittests from Buildbot to Mozharness'

Goal of this talk: To explain why the above is important and explain why it is
helpful

what does this have to do with release engineering?

'so before I started interviewing for this intership I did the normal
preperation of wikipediaing what the job description entailed.

Release Engineering:
'concerned with the compilation, assembly, and delivery of source code into
finished products or other software components'

'So really no surprises there, I was confident going in. Then I started looking
up actual Mozillian Releng personal blogs... It turns out that in Mozilla, the
above definition simplifies the process and fails to encapsulate Mozilla
Releng.

Continuous Integration (Mozilla Release Engineering)
'being conscious of time durations and in preparation for scaling software that
spans multiple platforms, versions, and locales, provide an infrastructure for
maintainable repositories that are put through continuous, in parallel, automated
builds, tests, evaluations, and ultimately, releases.'


what is Buildbot?
In laymans terms, buildbot is a python based system that helps us complete our
continuous integration by providing a master slave configuration where master machines 
tell slave machines what to do.

what is Mozharness?
'Mozharness is a configuration-driven script harness with full logging that
allows production infrastructure and individual developers to use the same
scripts.'
     - Aki Sasaki

'So far, I have covered the title of what I am doing...'

'Now I want to talk about what I did.'

We work with QA and Automation who take care of harnessing unittest suites like: mochitests,
reftests, and xpcshell, etc and wrap in those efforts in buildbot over a thousand machines
describing when and how to run them.

This can get pretty complicated when all the logic is nested in buildbots
walls. By walls, I mean spread over thousands and thousands of lines of code that
have to handle not only unittests specifics but lots of other stuff that shares
the same logic. Furthermore, all this 'logic' is on the master side and has to
tell each slave every little step what to do'.

By extracting all of this out, we get an in hindsight fresh start and can move
a ton of the 'how' out to the slaves themselves by telling them to run one
mozharness script.
On top of that benefit, we also get mozharness bells and whistles, flexible options,
and these tests are not restricted to just within buildbot. That last point could
really be taken further and help out individual developers. Imagine not only being able to
'rent' a slave outside of buildbot and run specific (or all) unittests but you
could also fire up a VM or ssh into a remote machine and run only xpcshell
cause you know its failing. All you need is python and virtualenv installed...


SLIDE   Before I quoted Aki as Mozharness being a script harness with configs, logging,
and actions.

Basically this means its very vague and broad.

This turns out to be a good thing. 

SLIDE   The way I think of mozharness is its a tool
to get from A to B. 

Think of a gps. The gps itself is the script you wrote. It has no maps
preloaded and is a paperweight without any.
As far as what the gps can do (waypoints, modifying terrain levels, track routes),
these are the 'actions' you define.
The memory cards that carry maps for differen't cities are the 'configs'
Finally the display that renders all your waypoints and tracks your
journey, are the logs that allow you to interperet sanely what you did.

SLIDE   Why am I describing Mozharness like this?
My hope is that some of you might discover a way to use Mozharness (like I did) in your
own projects and add to its fast growing base.

SLIDE   Mozharness Naked:

[pic of actions, configs, logging]

SLIDE   Mozharness with Unittests:

[pic of my stuff with similar views]