Q&A: "Continuous Integration to Continuous Deployment with Jenkins and Deployit"

These are some of the questions we received in response to our recent webinar with XebiaLabs:

Continuous Integration to Continuous Deployment with Jenkins and Deployit

Q: How easy is it to incorporate Ant scripts into Jenkins?  Does it require changes to build.xml?
Mark: It’s very easy: just create a free-style Jenkins project and in the Configuration for the Build phase, click on Add build step and select Invoke Ant:

Jenkins Configuration Build phase

No changes are required to your build.xml.

Q: How do we get the output of the shell script and compare it to a value for correctness?
Mark: We just published a blog on this very topic: Scripted Integration Tests with Jenkins and CloudBees

Q: How do you manage configuration, DB migration etc. dependencies with Jenkins?
Andrew: Using the Jenkins Deployit plugin, you can package configuration files and database scripts in your deployment package, and Deployit can take care of these during deployment too. Database updates, for instance, are incremental, so you can use the same package for version X to update an environment with version X-1 or X-2 as well as creating the database from scratch in a brand new environment.

Obviously, a prerequisite for this is that your configuration and DB scripts are either part of one of your builds or are available from a repository so they can automatically be retrieved for packaging. For further details, please see: The Deployit database plugin documentation

Q: Are there many companies actually deploying automatically right through to production and reducing the amount of ‘bulk’ release cycles they undertake?
Andrew: Good question! I guess that ultimately depends on what you mean by “many” ;-) There are certainly a number of large and well-known companies doing this: Google, Facebook, LinkedIn for example. But it’s definitely not in use everywhere, and there are many business scenarios in which this does not currently make sense, for instance if you have a defined release cycle with your customers or if you are unable to obtain approval for automated deployments to production. 

That’s one of the main reasons why we think it’s important to first of all think about what the initial and medium-term scope of your pipelines should be when considering continuous deployment.”

Q: How does the validated merge feature deal with the inherent lag involved in extensive testing?
Mark: There are two places a merge can happen. The one is before the submitted change is put to test —- the user submits proposed changes to a branch, and Jenkins will merge that against the current tip of the said repository. If this merge fails, the submission gets rejected, and the user needs to perform the merge and then resubmit the result. I think this is how it should be.

There’s the second place where a merge can happen, which is when the validation finishes and right before Jenkins pushes the result into the upstream. There’s a chance that someone else has pushed to the branch in the mean time.

You can resolve this situation in two ways. You can either tell Jenkins to merge it and push it automatically, at the expense of possible regression. You can also tell Jenkins to fail in this situation.

Q:  How does validated merge work with SVN?
Mark: The validated merge feature we discussed on the webinar is for Git.

For more about how this feature works, please see https://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-validated-merge-plugin.cb

For Subversion, Kohsuke has developed a plugin in open-source. See https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Merge+Plugin

Q:  How can you setup Jenkins so users can view config but not save? 
Mark: There is a Read-only Configuration Plugin for Jenkins

Please see https://wiki.jenkins-ci.org/display/JENKINS/Read-only+configurations+plugin

Q: Can we add Jenkins to IBM Portlet projects?
Andrew: For sure! Jenkins supports pretty much any build process as long as it consists of automatable commands. So no “open GUI and click here” but basically everything else, including the compilation of Portlet WARs, which I’m assuming is what you’re talking about. 

From a continuous delivery perspective, Deployit’s WebSphere Portal plugin supports deployment of the compiled portlets to WebSphere Portal, as well as the deployment of themes & skins, portlet pages and similar WP configuration. With these, the interesting part is how to automate the export/generation from your authoring environment using e.g. xmlaccess.”

Q: Can we use Vagrant or VirtualBox with Cloud Jenkins instance for distributed architecture?
Mark: There is a VirtualBox Jenkins plugin: please see https://wiki.jenkins-ci.org/display/JENKINS/VirtualBox+Plugin

Andrew: You might also want to look at the jclouds Jenkins Plugin but please note that VirtualBox support in jclouds is still in “labs”

Q: Are there approval roles for Deployit like “UAT” and “production”?
Andrew: Deployit supports full role-based access control linked to your enterprise user management such as your LDAP or SSO. The Jenkins Deployit plugin allows you to define multiple credential sets so that you can use these different roles for your Jenkins jobs.”

Q:  Do you offer repository management solutions like Nexus?
Mark:  The CloudBees PaaS offers cloud-based Git or SVN repository services: please see CloudBees Private Maven Repository for more details

Andrew: Deployit focuses on deploying your application packages, it does not provide a replacement for a (Maven) repository of your individual code artifacts in the way Nexus, Artifactory or Archiva do. In fact, many of our users store their deployment packages in Nexus or one of the other solutions and want to import these packages into Deployit, which is possible.

Q: The demo showed a Deployit application running outside of Jenkins: where does this come from?
Andrew: Deployit is XebiaLabs enterprise application release automation solution. Please see www.xebialabs.com/products or contact us.

Andrew Phillips vice-president of products XebiaLabs

Andrew Phillips is vice-president of products for XebiaLabs, providers of the industry-leading release automation solution, Deployit. Andrew is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. Sitting on panels and driving blog and social media conversations, Andrew regularly contributes to key trend-defining technology discussions.

 

Mark Prichard is Java PaaS evangelist for CloudBees. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was product manager for the WebLogic Platform. A graduate of St John’s College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA. Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.