Release Engineering as a Force Multiplier

In this post, I will post my understanding and its keynotes about http://oduinn.com/blog/2013/06/26/release-engineering-as-a-force-multiplier-at-google-techtalks/ , http://oduinn.com/blog/2013/06/07/release-engineering-as-a-force-multiplier-relengcon-2013/

Nowadays, Release Engineering is important to the success of every software project. People might find that more and more companies provide positions in Release Engineering and I am optimistic that there will be more and more people become professional Release Engineers in future. I am surprised that the world’s first ever Release Engineering conference was held in SF on this May 20th 2013! The industry should have realized the value of Release Engineering earlier!

Building an effetive pipelines (in my current company, we call it ‘flow’) requires a different mindset to writing a great software product. Release Engineers != Developers. I ever interviewed with some candidates which have good background in coding however they seems don’t have a good sense in Release Engineering. In their mindset, they just think that release engineering is just a job writing shell/perl scripts and nothing much! Hmmm, I understood that it is very common as Release Engineering is not taught as a discipline in any computer science. When I graduated from university in 2009 and started my career as a Release Engineer, I ever had any sense of Release Engineering. In my first 2-3 years, I had to learn on-the-job. This limits the effectiveness of Release Engineering to what can be learned on the job, and because information isn’t widely shared, its hard to learn from other people’s mistakes or successes. I am planing to write a booklet about Release Engineering to introduce the concept of Release Engineering, how it works, and what tools/scripts they will utilize, and how to be an seasoned release engineer, etc. That is also the reason why I opened this blog – I want to introduce Release Engineering to others. 🙂

When an organization encounter that its software delivery is slower and the product qualities are worse than before, and find that increasing headcount in dev & QA could not ease this pain. Yeah, show off time of Release Team. Release Engineers make entire organizations more effective while dev make good quality software. In the keynote, the speaker lists below data from his org (Mozilla):

Before & After

How quickly can we ship a chemspill release?

4-6 weeks 11 hours

How long to ship a “new feature” release?

12-18 months 6 weeks

How many active code lines?

1 1/2 42

How many checkins per day?

~15 per day 325 per day

I also have similar experience in my projects. We have nightly builds, checkin builds, branch builds, mainlines builds for different platforms and versions. Without this kind of build & release support, our dev & qa could not focus on their daily activities. Besides build & release, I also provide internal automated tools for them.

Who are Release Engineers’ customers? Haha, interesting topic. In the keynote, speaker provides two kinds of customers, Founder(s), CxO and VP Eng. Think those people are too big to us? Let me share you a real lesson. In my first job, I had ever done an info sharing session with one of our big boss who came from Headquarters by sharing her about Release Engineering team and how it works. However I had only 1.5 years working experience and I was still a newbie in Release Engineering. I had a bad presentation in this session because in this session, I shared her about what tools/ what techonoliges we used however seems she was no interested in that. In next paragraph, I will show what they are interested in. Here, I just want to convey that as a release engineer, you are closer to upper management than you think. Upper management they don’t care what tools/languages/technologies you are using, what they concerns are, how fast software can be delivered and how are the product quality. Release Team is in a good position to answer these kinds of concerns. Besides upper managements, we also have to walk around, chat with Dev+QA and find what do they care about and what do they need? And then do our best to comfortable them and improve their productivities. Basically we should be able to answer below problems (They are also the things what does upper management care about):

• fallout from shipping bad release
• fallout from slow response to security problem
• losing customers because of buggy software

missing release schedules during feature wars
(webM, …)
• turning away potential revenue
• infrastructure limits to hiring more developers

http://oduinn.com/blog/ is a very good source to learn how Release Engineering runs in a source organization.