Skip to main content

The Cost of Continuous Delivery

Continuous delivery is a process in which developers can land features on master (or trunk if you're on subversion), have it run through continuous integration (unit tests, user interface tests, service layer tests), have it propagate through the various stages of your deployment pipeline and have it on production in short matter of time. It sounds great because you'll never really need an ops team anymore and really dispels the need to have iterations (in 2 weeks, a feature lands, instead, a feature lands when it lands).

A build pipeline like that saves money for the company in that respect and makes it so that engineers can react more quickly to problems without having to go through layers of communication; however, it surfaces many more issues. As a software engineer on a fast pipeline that is continuously delivering to customers, it is increasingly more important to have test coverage. Below is a list of aspects of testing that need to be seriously thought of
  • Unit Testing
  • Web Service Testing
  • User Interface Testing
Taking a step back, in order to really take continuous delivery seriously, we should always look at the true value of having automated tests. Here are some of the core principles of automation testing:
  • To protect our users from misbehaviours in the system (never cause distrust between the product and the customer)
  • To be vigilant on any changes to the source tree (new and legacy code can be fractured easily)
  • To be able to verify functionality in an automated fashion without increasing engineering manpower (reducing costs -- people are the most expensive aspect of running a business)
With the above, automated tests in a continuous delivery model should now a part of the feature itself. Without tests, it is not a feature and it should not be able to land on production as it would be too much of a risk to the product and the customers. The most difficult part of absorbing the cost of continuous delivery is convincing the stakeholders that the new model is faster but needs more checks along the pipeline. This cost of continuous delivery (Jidoka) includes

  • spending time writing unit tests
  • spending time writing service layer tests (assuming your platform follows SOA, validating inputs/outputs of data)
  • spending time writing user interface tests that detect defective user flows (registration, updating profile, etc)

In the end, following the guiding set of principles of Jidoka allows your engineering teams to produce high quality features by detecting defects along the pipeline and ensuring there's fixes in place to keep the pipeline pushing forward.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software engineer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Bacardi, Nike, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's writing open source software and helping developers in the Windows Azure NodeJS community.
Post a Comment

Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.


World of Warcraft Ninjalist addon: version 0.1 coming along quite nicely

After toying around with more GUI related issues in World of Warcraft's API, I've decided to take a totally different direction. Originally when I architected this addon, I knew in my mind it would be a super simple Console application that a user could easily paste in a name and add it to the database; however, why stop there?

After discovering AceGUI, I can easily start developing UI components in no time! As of right now, I've got it saving data in between game sessions--the interesting part will come when I'll have to develop the web service that will parse the SavedVariable.lua, eliminate duplicate entries, as well as, do a huge merge between their copy and whats on the server's (per realm basis of course).

Here's a screen shot of the responses when adding new Ninjas to your list:
When a user clicks add after entering a name in the textbox, it'll go ahead and add that person to the ninjalist tagging the user's realm and current date/time. Someday, I…

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:

Now, whenever you make a commit, it should show up like this in the log:

Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this

Want more emojis? check out the Emoji Mardown Cheatsheet!