2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- October 5, 2016
- Integrate Continuously
We want to make invoking the build as simple as possible. So simple in fact, that it becomes a non-event that’s nearly invisible to us.
The build should be accessible from the desktop or in the IDE. It should require only a single click to invoke.
A local build should be invoked first, compiling only those modules that have a direct dependencies on the changes that have been made. Once those modules have been recompiled the corresponding unit tests should be invoked, and if all of them pass the code should be automatically promoted to the build server to be integrated within the system and invoke a larger suite of unit tests. If all of these tests pass, then, if desired, the system can actually promote it to production.
All of this can happen automatically, with a single click on the developer’s machine.
Of course, we don’t have to release to production whenever a developer has a successful build but we could if we wanted to. By making the build automatic we’ll run it more frequently and reap the benefits of feedback more consistently from our build system.
There are even tools that automatically run the build for you automatically as you’re typing code, so you don’t even have to bother with that single click to invoke the build.
NCrunch for.net (http://www.ncrunch.net/) and infinitest for Java (http://infinitest.github.io/) are plug-ins that run in the background waiting for developers to type keystrokes into their IDEs. When they type something in that can be compiled, a build is automatically launched. This means you can be happily typing along and when you come to the end of the line and type semi-colon, the system automatically builds what you typed. Within a few seconds you get feedback on whether or not it worked.
A single click may not seem like a lot of effort but we invoke the build many times a day when we’re writing software. Making it even easier to invoke the build than one click can have far reaching implications for improving developer’s productivity. Getting immediate feedback on what’s being built is also immensely helpful. It gives us the opportunity to find bugs as they’re written so we can fix them immediately and with little effort. When a bug gets past the developer and QA finds it days later it can take much more time for the developer to go back, figure out what she was doing, understand the bug and fix it.
We want developers to run the build all the time because every time they run the build there is an opportunity to get feedback. If the build fails then it was probably caused by something done since the last time the build was run, which is usually just a few minutes ago so it’s easy to find. If the build is successful then our confidence rises because we know things are working as they should.
Previous Post: « More Comments on Code Comments
Next Post: Version Everything! »