Time Between PR Merge and Live on MDN

[Joe Medley]

I'm curious, what is the typical time between when a PR is merged in mdn/data or mozilla/kumascript and when it shows up on MDN?

[jwhi...@mozilla.com]

On Thursday, March 2, 2017 at 12:43:52 PM UTC-6, Joe Medley wrote:
> I'm curious, what is the typical time between when a PR is merged in mdn/data or mozilla/kumascript and when it shows up on MDN?

MDN is updated with the latest code (including KumaScript macros) about once a week, on an irregular schedule. KumaScript loads from mdn/data's master branch, so those changes go live when they are merged.

From the view of updating MDN, KumaScript is a submodule of Kuma, the Python code behind MDN. Kuma needs to be updated to bring in the new KumaScript changes. I can do this with a manual commit [1], or it can be done by opening and merging a pull request [2].

I try to update KumaScript just before a staging and production push. I'm much more aware of what's going on with Kuma, and I need reminding that KumaScript changes are pilling up. Often, I get a request from MDN staff in the #mdndev IRC channel [3], which is the fastest way to reach me.

The process to update production takes about two hours:
- Check out the Kuma master branch
- Review the changes since the last deployment [4]
- Review and merge the KumaScript master branch
- Update translatable UI strings, if needed
- Deploy the new code to the staging server [5]
- Run the browser-based tests [6]
- Manually test the changed functionality on staging
- Deploy the new code to the production server [7]
- Monitor production for 60 minutes on New Relic
- Update Bugzilla, Taiga, and other project management tools to say that code is live in production.

None of this is particularly difficult, but it takes concentration and can't be done at the same time as writing code. Once a week is about right.

The process is what it is because of lessons learned from bad deployments over the last five or more years. My goal is to make this process faster while maintaining reliability, but that work has to be balanced with other team goals.

John

[1] https://github.com/mozilla/kuma/commit/2b7e36afe0bda1fcd44a9f2483b92e2e8e9d6c13
[2] https://github.com/mozilla/kuma/pull/4138
[3] https://wiki.mozilla.org/Irc
[4] https://whatsdeployed.io/?owner=mozilla&repo=kuma&name[]=Stage&url[]=https://developer.allizom.org/media/revision.txt&name[]=Prod&url[]=https://developer.mozilla.org/media/revision.txt
[5] https://developer.allizom.org
[6] https://kuma.readthedocs.io/en/latest/tests-ui.html#run-tests-on-mdn-s-continuous-integration-ci-infrastructure
[7] https://developer.mozilla.org, of course

[Eric Shepherd (Sheppy)]

Our reliance on KumaScript macros to implement features like the sidebars and automated generation of article lists makes once a week sometimes awkward, but survivable. In a perfect world, features that are closely tied to content (like sidebar changes, etc) would be handled by the platform itself — or at least those macros would get updated more often.

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy