Is anyone doing Continuous Deployment (CD) / DevOps with Intersystems Products?

[GBmav]

Hi

Is anyone using Continuous Deployment toolsets with Cache to build , test then deploy Cache applications?

e.g.

jenkins for CI - http://jenkins-ci.org/

and chef or puppet for deployment?

http://www.getchef.com/chef/

http://puppetlabs.com/puppet/what-is-puppet

http://www.ansibleworks.com/

if so does anyone have any advice on optimal tools or issues when integrating with cache/Ensemble?

[Paul Rapoza]

I am late to this, I too have been tasked to use configuration management/DevOps to help move applications between environments (DEV, TEST, STAGE and PROD).  I se the tools below, do they allow us to use CM to do this?

[OldMster]

Christopher Edwards over on the HardHats group has done a lot of work with Vista and Vagrant. It isn't exactly the same, but other than the VA Vista KIDS deployment model, I think it is the closest effort.

Mark

[Seb Patane]

Hopefully not too late.

We've got a full CI setup with Cache using Jenkins and an extension of the %UnitTest classes that we picked up a few years ago from a Global Summit session.

Previously, we had a simple unstable-master development flow where everyone committed to master (next version) and backported to a stable-branch (currently released version)

* On commit to GitHub, Jenkins calls a custom build script (sadly no %Installer yet) which then builds, packages the Cache.dat's and uploads the pachage to our ftp server

* Jenkins will then run the unit tests suite on them, which notifies the committer on failure

  * Any failures are generally fixed almost instantly

* QA will generate an alpha build with a few changes in it every few days to manually test with

* Once we want to release, we make a tag in GitHub with Jenkins picks up and compiles & packages a production release

Recently, we've decided to try branch-based development with a stable master. We found our releases being pushed back too often by work in progress, having master only contain finished work means we can release at any time.

* It's pretty similar, but instead we make a branch off master for our change that looks like <bug number>-some-short-description

* Jenkins picks up and builds each branch when they get updated, unit tests them and packages them for manual testing

* QA manually downloads each branch package and test it

* Once everything has tested ok, unit tests have been created and documentation is done, another developer does a code review and merges into master

* Before release, QA sanity test master, though unless any tests have failed (in which case the work is merged out) it's safe to assume it's stable

We properly started branch-based development last week, so still TBA to see how well it goes.

A few other things about our unit tests

* We require at least one test to be written for each bug/feature (excepting certain legacy code)

* We also have javascript tests (our app is 100% zen/web-based), but still need to set up something like karma to run these automatically with Jenkins

* We extended the Unit Test framework to

  * Use Cache transactions to automatically roll back test data/changes

  * Kill any variables in the global legacy scope (to prevent cross-test interference)

  * Record individual test metrics using the %Monitor.Process class

* Each test has to generate any test data it needs to run (we use an extended %Populate utility that is a little friendlier)

* We chart performance data for each commit in Jenkins (global refs/sets/kills, journal entries, routine lines executed/loads/fetches, locks success/failures) 

  * No alerting for performance regressions yet :(

Regarding deployments, I've toyed with Chef to do system configuration for IIS/Cache, but haven't had time to get very far with it (mostly learning Chef). I believe InterSystems used Chef/Puppet to orchestrate their "field test Cache 2015.1 on EC2" thing last December, so they might be able to chime in?

I've also been investigating Docker heavily which is going very well. It's very cool to instantly have a fully working Cache instance + application with nothing more than a single docker run command. I also found it a lot simpler to pick up than chef/puppet.

The end goal for our CI system is to get to full continuous deployment - ie. when features get merged into master our sites get updated automatically and can immediately start using them and giving us feedback. We're not quite there yet, but working towards it.

Cheers,

Seb

[John Murray]

If you haven't already gone down the path of externalizing your Cache/Ensemble sources into files that tools such as Git and SVN can use to provide versioning, then maybe take a look at our VC/m tool. As well as doing version control natively inside the InterSystems environment it includes comprehensive features for transferring code through whatever CM/DevOps workflow you need. By combining this with VC/m's COS-scriptable callouts it's possible to integrate unit testing into your workflow.

Please see http://www.georgejames.com/vcm for more information, or contact us via our webform.

John Murray
George James Software