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.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
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:
- Check out code;
- Compile/process the code;
- Analyze and report;
- 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:
- Track what’s new;
- Build ID that uniquely identify what’s included;
- Implant and enforce policy and procedures;
- Management of upgrade & patch releases
Top 10 Commandments
- 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.
- 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.
- Write portable and low maintenance build files: plan multi-architecture/OS versions; design/use templates; measure twice, cut one.
- Reproduce build process: adopt continuous build policy; use tools like Hudson and cruise control.
- Build number: ID, repository; date/repo version/release version; must be easily obtainable – make it included in packaging and embedded in binary.
- 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.”
- Design an upgrade strategy before releasing version 1.0.
- 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.
- Complete install/uninstall/patch/upgrade: totally automated process; rollback & forward; package relocate-able. “Playing nice with others is a virtue.”
- Apply these laws to yourself: can be applicable? Audit-ability and reproducibility.