The Heartbeat of a Project

For me, software agility is best summed up in the first principle from the Agile Manifesto, which talks about continuous delivery of valuable software.

Agile software development is supposed to be a flow that doesn’t conform to prescribed phases. Instead, it breaks projects down into features and tasks. We build the features that are most important to the customer first and we build them incrementally so we can show our progress and adapt new ideas.

A continuous integration server runs at all times, waiting for code to be checked in to version control. Just like our heartbeat, it operates in the background and keeps our projects alive.

Once code is checked in, the build server goes to work. It recompiles the projects and runs a whole suite of tests. If all tests pass, then it optionally promotes the release candidate to production.

We may not want to release our software as frequently as we update it, but it almost always makes sense to keep our software in a releasable state. When software is in a releasable state, the risk of a showstopper bug preventing you from building a system goes away. It also means that last minute changes are much easier to accommodate.

Remove all human intervention from building and validating release candidates. When you fully automate the validation of release candidates then you make one of the most expensive parts of software development: integration and testing, completely free. This takes an enormous pressure off the team, makes code more flexible to work with, and brings us into true Agile software development.

Remember to version everything—the build depends on including stored procedures, database schemas, configuration scripts, etc., not just source codes. Using standard configurations and a replicable set-up builds the reliability foundation a build system depends on.

There are a variety of techniques and approaches for speeding up the build, but the first step is to write good unit tests that only test what is needed so they run fast and have a good testable architecture. We can have thousands of unit tests that can run in just a few seconds if they’re well-written.

Of course unit test may not be the only thing required to validate a release candidate but the faster and simpler we can make this process, the more the team will appreciate it.

This is great !!!! I would add that no matter the courage of Agile team, in some organizations that I work before there was "fear" of the deployment to production. What if it goes horribly wrong? What if there are still bugs? Just for the one main " FEAR "reason alone, we need to have multiple environment where we can practice pushing from one environment to another. Fear is the mind-killer. Fear is the little-death that brings total obliteration. By Frank Herbert.

Like
Reply

So true. The rapid build/deploy loop has amazing technical benefits, but the team context savings and work validation feedback loop are huge by-products as well.

To view or add a comment, sign in

More articles by David Scott Bernstein

  • Green Tests and Red Tests

    In practice, I found that there are times that I want a bit more test coverage than I get from just doing test-first…

  • Radiators and Silos

    In the old days of corporate America, the way you got ahead was through hard work and perseverance. You strove to…

    2 Comments
  • Makers and Menders

    I’ve been getting back into some research interests of mine that require data acquisition from a variety of sensors so…

  • Core Developer Practices

    Every field of engineering has a core set of practices that they follow and software engineering is no different. But…

    1 Comment
  • Still XP After All These Years

    Are you humming in your head Paul Simon’s “Still Crazy After All These Years”? I am. And it does seem crazy.

  • The Importance of Continuous Integration

    Perhaps the most important yet easiest to implement of all the software development practices in Agile is continuous…

  • The Importance of Technical Practices (Again)

    Software development has undergone many revolutions over the last few decades. The way we build software today is…

  • Summary of Seven Strategies Series

    I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine…

    1 Comment
  • Refactor to Learn What Not to Do

    One of the things that I was not expecting when I started refactoring other people’s code was that I started to see…

    4 Comments
  • Refactor to Clean Up Before Moving On

    Of course, the best time to refactor code is while it’s fresh in your mind, right after having worked with it. Once I…

Others also viewed

Explore content categories