Must Knows About Release Engineering: Lessons From Google

This is yet another post based on my notes taken at LISA 2010 conference. The talk is The 10 commandments in release engineering by Dinah McNutt from Google. Dinah did a great job in summarizing the basics of release engineering therefore it’s worthwhile to compile my note and share it here.

Note that although typical release engineering does not produce virtual appliances, the basic principles are the same. You will find these basics helpful as well.

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

Release engineering is a critical part of software engineering and should be treated as products in their own rights. But often there is disconnect between development writing the code and the system administrator who installs it. Release process is usually an afterthought.

Typical Release Process

The following steps are executed during a release run:

  1. Check out code;
  2. Compile/process the code;
  3. Package;
  4. Analyze and report;
  5. Perform post-build tests

Note: any difference for virtual appliance? Mostly the step 3: instead of packaging it with an installer you package it into a virtual appliance.

The features of good release engineering include:

  1. Reproducible;
  2. Track what’s new;
  3. Build ID that uniquely identify what’s included;
  4. Implant and enforce policy and procedures;
  5. Management of upgrade & patch releases

Top 10 Commandments

  1. Everything should be under source control. It should include source code, build files, build tools, documentation, build results, build artifacts. Your OS, compliers should also be source controlled or backed up so that they can be restored when needed.
  2. Right tools for the job. “Unnecessary complexity is a sin.” Steve’s Note: It’s true not only for release engineering, but also for software development and probably for all engineering disciplines.
  3. Write portable and low maintenance build files: plan multi-architecture/OS versions; design/use templates; measure twice, cut one.
  4. Reproduce build process: adopt continuous build policy; use tools like Hudson and cruise control.
  5. Build number: ID, repository; date/repo version/release version; must be easily obtainable – make it included in packaging and embedded in binary.
  6. Use package manager: auditing; install/update/remove; summary (who, what, when, etc.); manifest; use native packaging manager whenever possible; built-in version tracking and dependency checking. “Tar is NOT a package manager.”
  7. Design an upgrade strategy before releasing version 1.0.
  8. Provide a detailed log of what you have done to my machine: able to upgrade and inspect the package; “do nothing” option so that I can see what’s going to happen.
  9. Complete install/uninstall/patch/upgrade: totally automated process; rollback & forward; package relocate-able. “Playing nice with others is a virtue.”
  10. Apply these laws to yourself: can be applicable? Audit-ability and reproducibility.

This entry was posted in Software Development and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.