What are the major obstacles (and potential solutions, if known) for implementing “continuous delivery” software development when an application relies on varied programming languages or modules… especially when the same version-control and/or automated testing packages do not exist for those disparate platforms?
For example, a Java web application that is deployed and running on a Linux host, talking to a DB2 database back-end via JDBC, with occasional calls to stored-procedures that wrap RPG or COBOL or C programs on that same back-end? What if the code for all of that cannot be contained in the same version-control/source-control system?
Is it possible to get to the illusive “push-botton release” in this situation? Or do you have to have EVERYTHING in the SAME VCS? Additionally, how would one manage the creation/modification of database schema, and so-called soft-code control values in the database?
Is there a more-or-less “canonical” published work on this type of thing?
1
The fact that you have these different development platforms should not be an obstacle in terms of continuous delivery. The complexity of interacting with these platforms is managed by your build tool and most tools have support for the environments / platforms you mention.
For example with CruiseControl.NET you would have a task that checks out your Java web app (it can interact with git, hg, svn, visual source safe etc), that is then compiled according to the definition in the project build. Deploying it to a Linux host can be done over ftp or UNC paths, in fact if you can script it in a command line then you can just use that in your CCNet build.
The more challenging part of CD is to migrate your database, but again this is not a limitation of the build process – if you can script the task then you can automate it with your build server of choice, be that CCNet, TeamCity, Jenkins or whatever.
In the .NET world the RedGate suite of tools are very helpful here, we use SQL Compare to compare the development copy of a database to the UAT environment and also the version controlled copy using SQL Source Control, it generates a script and we invoke the task with the command line interface provided. This then updates the database. Actually in DEV and locally we drop the database and recreate it, then seed it with data using SQL Data Generator, but it isn’t hard to script out the data to populate a clean copy of the database with. For production it’s obviously harder as we can’t drop the database and migrations are required and these we again lean on red gate for, but can be manually created and dropped into the build resources so the build server can apply them as part of the CD.
In terms of a good source of information check out a series of posts by Roy Osherove that discuss some best practices, or Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble
2
Inedo’s BuildMaster is a tool designed to handle scenarios like this. The “secret” is that it’s not a project-centric tool (as traditional CI might be), but it models applications and their deployable components. As such, there are lots of users who have multiple VCS (from Git to ClearCase) to build applications on multiple platforms (Java, .Net, etc) on multiple operating systems (Windows or anything SSH-supporting).
There’s a free version of BuildMaster that could probably handle a lot of the problems you’re trying to solve. If you’re familiar with The Daily WTF, Alex wrote a nice (but but long) article that introduces the platform. He’s behind the site, and also the founder of Inedo.
(Disclaimer: I work at Inedo)