2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
(c) 2024 To Be Agile
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.
Previous Post: « Implementation Independence
Next Post: Comments on Comments »