Continuous Development and Deployment : to Git or not to Git a “Solution”

In the bad old days of software development, the typical (waterfall) release cycle took anywhere from 6 to 18 months from requirements to delivery. These periods would include, in sequence, UML modeling of the requirements, complete source code development, quality assurance processes, compiling, building, packaging and shipping. If requirements changed mid-cycle, often times this meant resetting the development cycle back to square one and starting over.

With the rise of the commercial Internet, delivery methods and timeframes began to change. Customers started downloading packages, updates, and documentation rather than waiting for them to arrive in the mail. So called “agile” methodologies attempted to shorten the development-delivery cycle from 3 weeks to 3 months. The era of formal scrum and extreme programming methods arose to whip lazy engineers into shape. As delivery cycles shortened, reasonable expectations were quickly replaced by the need for instant gratification.

Major software libraries and frameworks that now power the Internet have, at the absolute worst, a nightly build (24 hour delivery cycle). The norm is continuous integration and delivery. This typically means that as a developer commits a chunk of source code to the repository, an automated build and delivery process is triggered automatically. If that source code is flawed, but somehow manages to pass the full test suite, it still can wind up in the hands of the end user who performs another round of QA by default. Thus, most frameworks and libraries have older “stable branches” and newer “unstable branches”. The former is considered generally safe for production dependency, whereas, the latter is considered “use at your own risk” code.

Versioning has always been important, but in a continuous delivery system it is critical.

In our system we suggest:

  • maintaining “module” repositories with branches and versions in Git
  • maintaining “solution” build versions in archives supplied by Jenkins and stored in S3

The effect is that everything that was needed to build the a “solution” version is available to the developer to download and do maintenance or further development on a product that exists in production.

In the CleverStack scenario all we see upstream are modules, and no one is managing their effective releasable combination.

Our proposal, to use the test archive from Jenkins as a version build archived to S3, takes care of the complex interrelationships as a release which can be used as a foundation for further work on a product.

Leave a Reply