Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Diving into DevOps details

Matthew Heusser | June 19, 2015
Search for a definition of DevOps and you're likely to find something involving a collection of other buzzwords, like "agile," "system administration" and "lean," that doesn't actually tell you anything. We think we can do better.

Another way to do it is to increase the support responsibilities of the development team. For example, a programming team could take over all responsibility, from build to deploy to support, rotating a programmer through support, two weeks at a time. This would give the developers broad exposure to how the codebase worked from the outside, and also help them feel the pain of supporting their own work. (A smaller operations group still needed to support some infrastructure, like the production servers and databases.) 

Automating the build

Continuous Integration (CI) tools are probably the most popular and widely used of those expressed here. Some companies continue to perform builds, but the potential for automated builds goes beyond the compile step. It can include logging and tagging builds according to branch, storing the exact build in an archive connected to the commit number and branch, and, possibly, connecting builds to features. 

Once the build is complete, it can also run all the unit tests all the time and then actually deploy the software to development, test or staging server. CI tools can then run web services or GUI end-to-end checks to see if something major failed with the new code. This is not continuous delivery the code is not automatically pushed to production on every commit. (Some organizations buy a new, fresh, virtual server from scratch for each deploy, instead of "upgrading" a single development environment; some create multiple virtual environments, one or more per programmer.) 

If the damage a defect can do is a function of its severity and how many people see it, then finding the problem soon and fixing it fast can limit the damage. Finding the problem when it has been exposed only to a small percentage of users is not always possible but visual monitoring and altering can help. 

There's a great deal of information on server logs from how long requests are taking to serve to how many 404 and 500 errors the system is experiencing. By visualizing those errors in a graph, perhaps using opensource tools like Graphite, the team can see problems as they happen and take action. 

Once the work is feature complete, the steps of a production rollout can be automated and put behind a Web page or at least a command-line interface. When the CI server does the next build, the continuous deployment system just needs to go one step further, to production. 

Push button deploys lead to pushbutton fixes, which combine with production monitoring to drastically reduce the timetolive (TTL) of a defect.

Configuration flags

Config flags are a mechanism to reduce time-to-live even further. Instead of needing to change the production code, the programmer changes his code with an "if (feature) { }" block around the new code. To roll the feature back, the programmer changes a file on disk that stores the flag as on or off. As this is not a code change, it doesn't require a new build/deploy. Noah Sussman's "Config Flags: A Love Story" covers the concept in much more depth. 

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.