2

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?

PattMauler
  • 123
  • 3
  • I'll assume your back end DB2 machine is running IBM i (formerly known as OS/400), since you mention both RPG most prevalent on that platform. I would be very interested if anyone has thoughts on continuous integration in that environment. I haven't heard of any. – WarrenT Feb 13 '13 at 18:10

2 Answers2

2

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

Simon Martin
  • 1,006
  • 8
  • 18
  • I'm currently reading Humble's "Continuous Delivery..." book. I don't think I'm at the point where I can fully grasp how to "put it all together". Is it an empirical statement to say, "if you can script it, you can integrate it with continuous integration/delivery"? Part of my problem may be that I'm not an RPG developer, so I don't have an idea of what tools or means are necessary to make the right things happen on that platform. – PattMauler Feb 12 '13 at 15:33
  • Given that a build server runs and controls scripted tasks, if you can script it then you can integrate it into your CD process. But if you've not got a continuous integration process in place then I would start by doing so, to make it deliver is just an extension of that process. I'm assuming you're using something like Maven for your web app which you can invoke from your IDE or manually. You would get your build server to invoke that in order to build your web app. The same is conceptually true for all the other steps in the process – Simon Martin Feb 12 '13 at 15:41
1

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)

Karl Harnagy
  • 121
  • 2