9 June 2017
Make rapid, iterative releases.
Even if only for internal purposes such as a candidate for official deployment, issuing small releases builds upon the notion of adding or changing only one thing at a time.
All of this, however, is an extension of where and how to begin.
Start with a trivial system that represents the main workflow or dataflow. As the very first version, the system does nothing but does it correctly.
Then give it data. Perhaps begin with fixed values hard-coded rather than loading from storage, because costs involved with reading bits off disk or network is an additional step in itself beyond dealing with the data. There may be something to discover about the data structure first.
Go back to first principles of a program: something goes in, something goes out, and do something in the middle.
Beginning with this over-simplified model keeps one grounded during the early versions, which accommodates a clean implementation for ease of adding more functionality later.
As the project matures, more people contribute, and facilities such as continuous integration are involved– this model becomes the pragmatic approach.
A good use of continuous integration produces nightly builds as if each one may become a release candidate. Of course, if the build fails, the candidate is disqualified. Of those that complete and automated tests pass, people finish qualifying the candidate from the same nightly build. Finally, it’s a business decision about when or if to actually promote the candidate to be a release. It’s then another business decision whether or not to make the release available to customers, and this process applies regardless if they are internal or external customers.
Each feature branch merged from the code repository should trigger the release candidate pipeline.
Measure the value of each release by how it would impact the people using it. If doing bug fixes, the value is more stability for your customers. If code clean-up was the focus, the value is having resolved technical debt which is more of an internal concern, so while that version may become available to share internally within a company, it might not be released to actual customers.
Beware the tendency of some to release too quickly, which has the knock-on effect of introducing programming errors. Some developers release too soon and without adequate coverage in their tests. Proven methodologies should still be applied.
The point here: granularity of each iteration should be small with focus on reliablity.
The goal is to minimize missteps, and ultimately minimize programmer errors.