{"id":5204,"date":"2014-05-02T16:14:48","date_gmt":"2014-05-03T00:14:48","guid":{"rendered":"http:\/\/www.chesnok.com\/daily\/?p=5204"},"modified":"2014-05-02T16:39:14","modified_gmt":"2014-05-03T00:39:14","slug":"release-engineering-a-draft-of-an-architecture-diagram","status":"publish","type":"post","link":"https:\/\/www.chesnok.com\/daily\/2014\/05\/02\/release-engineering-a-draft-of-an-architecture-diagram\/","title":{"rendered":"Release Engineering: A draft of an architecture diagram"},"content":{"rendered":"

One of the things that I like to do is create architecture diagrams of complicated systems.<\/p>\n

We had Release Engineering and Release Operations in the Portland Mozilla office this week, providing a perfect opportunity to pick everyone’s brains about what the current state of our release infrastructure is like.<\/p>\n

Behold: \"releng<\/a><\/p>\n

And here’s a version that includes some “tree closure reasons” in magenta:<\/p>\n

\"Releng<\/a><\/p>\n

A tree closure is defined as an hg hook that prevents people from committing to a tree (like mozilla-central). It looks up status at treestatus.mozilla.org<\/a> to figure out whether or not the tree is closed, and this value is updated manually by “sheriffs” who track tree status.<\/p>\n

And the an initial key to the tree closure reasons (the numbers on the magenta blobs), is documented on the Mozilla wiki<\/a>.<\/p>\n

The goal of this document was to take brain dump information from everyone in the meeting, and create a relationship diagram of all the systems that everyone here supports. As you can see, it is pretty complex.<\/p>\n

What I took away from creating this was:<\/p>\n