rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

Repeatable Builds will Set You Free

My current project for a leading commerical transportation company reminds me of some things I hold as true and self-evident...

The reason builds need to be automated and repeatable is that an automated build is the *only* tangible, qualifiable version of the truth. There are just too many moving parts in software development projects and the build is your safety net to ensuring that there is a control state that puts all of the applications, components and services in balance at least once a day.

As a development team, you need to stick to the truth and get back to the truth as quickly and effortlessly as possible because the real effort should be in delivering software, not drowning in the quagmire that is deployment and configuration.

Take the time to set up your build from day one, and as you add logical applications, include a deployment step to a neutral integration environment.

You will immediately realize the following benefits, literally over night:

  • No more wasted time compiling, XCOPYing and dilly dallying with config files. Set it and forget it.
  • The establishment of a regular rhythm  that promotes accountability, daily code check-ins, and a steady beat of the drum to keep the team in perfect sync.
  • Full integration of the compilation process of all applications in your solution. No more “But I can compile locally…”
  • Daily integration (if not more frequent) of each application with the environment. No more “But it works on my machine.”
  • The ability to smoke test in a neutral environment that everyone agrees to. Huge moral booster because every day, if not more often, you know your software works.
  • The ability to execute both isolate unit tests, and integration unit tests on a live, just deployed system. You can speak accurately as to the health and status of your project and each application within it.

Time and time again, it is a repeatable build process that has made the difference between success and failure on so many projects I've worked on. I just don’t think you can afford to forgo it on any non-trivial project.

Print | posted on Wednesday, August 12, 2009 2:05 PM | Filed Under [ Processs ]

Comments have been closed on this topic.

Powered by: