Here's the main DeployIt configuration from the Developer/PetClinic Build Job:
Here's the DeployIt plugin configuration used in the QA/Deploy to Prod, QA/Deploy to QA and QA/Deploy to Test build jobs - the details of the environments used for these deployments is configured in DeployIt and you can see Andrew demonstrate this on the webinar recording:
Finally, here's the configuration Andrew used for the SeleniumHQ plugin in the QA/PetClinic Functional Test build job:
Q: Please post pointers / links to the previous webinar if it was captured and able to be post-played?
This webinar: http://vimeo.com/53031852
First webinar: http://vimeo.com/49331238
Q: How do you manage the licensing and code signatures process for development on iOS, Android, Blackberry, etc.?
Please see the following articles on iOS/Android development and feel free to contact me (firstname.lastname@example.org) if you would like to know more about mobile development with Jenkins:
http://blog.cloudbees.com/2012/09/continuous-deployment-for-mobile-apps.html (iOS builds)
http://blog.cloudbees.com/2012/09/continuous-integration-for-mobile-apps.html (Android builds)
http://blog.cloudbees.com/2012/09/continuous-integration-for-mobile-apps_28.html (Matrix Android builds)
http://blog.cloudbees.com/2012/10/continuous-integration-for-mobile-apps.html (Beta Distribution)
Q: If i'm not using the promoted build plugin, I can't configure the job to build when approved?
Take a look at the Jenkins Build Pipeline Plugin. However, I would recommend that you use the Jenkins Promoted Builds Plugin, which is OSS and freely available - it makes this much easier.
Q: Does your product work with Subversion?
Yes, the Jenkins Subversion Plugin is very widely used and is actually bundled with the Jenkins installation, so there is no need to install it separately. If you are interested in using Jenkins in the Cloud for some or all of your build tasks, then CloudBees also provides cloud-based SVN repositories as part of the PaaS (Platform as a Service): please see here for an overview and this article for detailed instructions on moving a SVN repository to the cloud. Note that you can also use Jenkins In the Cloud with a locally-hosted SVN repository.
Q: For changes not yet merged into mainstream, do these pile up on a single branch, waiting to be merged? Or would each dev have their own branch and initial job?
The validated merge feature allows multiple developers to “propose” changes to the same branch. Those changes are built/tested/validated by a single Jenkins job. When multiple changes are proposed concurrently, you can tell Jenkins to do them in parallel (to increase the throughput but you need more computers), or you can tell Jenkins to do them in a sequence.
If you gravitate toward the model of having every developer own his own branch and his own Jenkins job, that’s doable, too, but if I understand your question correctly, there’s limited value of using the validated merge feature in this model because a regression in a developer branch doesn’t really negatively impact anyone else, so a developer might just as well push possible broken changes to his own branch anyway.
Q: Do you support nested groups for Active Directory ?
The short answer is YES! And we did actually work hard on it because (as you may know) Active Directory has 3 different group types that behave differently when you are in the forest environment, etc.
Q: Can the quality build hook up with Sonar?
Yes, please see: Codehaus - Sonar Hudson/Jenkins Plugin
Q: Is the Jenkins Deployit plugin freely available? (or exclusive to Jenkins Enterprise)
The Jenkins Deployit plugin is an integration component delivered as part of the Deployit Application Release Automation solution: Deployit Application Release Automation solution. Please see http://www.xebialabs.com/jenkins for more information on trying out Deployit & Jenkins in your own environment.
Q: We talk about Jenkins Enterprise in combination with DeployIT. Please could the speakers tell us, where applicable, if things can be used on Jenkins open source also?
The features that are specific to Jenkins Enterprise by CloudBees are listed and described here: Jenkins Enterprise by CloudBees. The Promoted Builds Plugin is OSS and freely available.
Deployit is currently not open source, although we have made various components freely available. See the previous answer for information on how to trial Deployit and the Jenkins Deployit plugin.
Q: Is the Maven configuration in pom.xml of your project for Deployit still necessary when you use the Jenkins Deployit plugin?
In most cases, no. The Jenkins Deployit plugin allows you to define deployment packages, publish them to Deployit and trigger deployments without any Maven configuration – you can even use it for non-Maven projects.
There are a small number of options that are provided by Deployit’s Maven plugin that differ between the Maven and Jenkins plugins, so if you are already using the Maven plugin you may want to double-check that.
Q: Is the build example shown a initial build?
In the example, we showed all the deployments were upgrades, although the versions already running were different across the environments. Of course, you can also carry out initial deployments via the Jenkins Deployit plugin: in fact, no changes to the job configuration are required – Deployit figures out automatically whether an initial deployment or an upgrade needs to be performed.
Q: 1) When you say, deployed to an environment, I guess you can configure multiple servers to deploy the applications to. 2) You mentioned that configuration is managed in Deployit, can you version the configuration as with the application/war? 3) Does Deployit roll out DB changes, run SQL against the target databases, etc.?
1. Yes. An environment can contain multiple “containers” – app servers, webservers, databases etc. – and you can map items in your deployment package to one or multiple containers.
2. There’s two types of “configuration” involved here. The first relates to resources such as queue or datasource definitions that are required by your application. These can be included in deployment packages along with your application artifacts and so are versioned alongside them.
The second type of configuration refers to environment-specific values used by Deployit to resolve placeholders in your deployment package, e.g. MYDS_PASSWORD -> “secret”. These, like all items in Deployit’s repository, are also versioned.
3. Yes. Deployit supports execution of SQL scripts and associated rollback scripts as part of application upgrades and downgrades. It will also perform an “intelligent delta,” running only those scripts that have not already been executed as part of the currently installed version, if there is one.
Q: Where do the environment variables come from?
Please see here for a list of environment variables set by Jenkins.
As described in answer to the previous question, Deployit also allows you to associate values to your target environments. These are stored in a “dictionary” – a set of key/value pairs like a properties file, basically – in Deployit’s version-controlled repository.
Q: What support is provided for Selenium?
Please see the following for details of the Jenkins Selenium Plugin: Jenkins Selenium Plugin. This will enable you to run a Selenium Grid2 cluster. CloudBees also partners with Sauce Labs, who offer a cloud-based Selenium test service.
Q: in a previous presentation you managed to give access to live working Jenkins on CloudBees at https://partnerdemo.ci.cloudbees. Can you do the same for this webinar ?
Yes, we will copy the build configurations to the partnerdemo account on CloudBees so that you can refer to details of the configuration. Please note that this particular webinar used a dedicated Jenkins Enterprise installation, so this is not a "working environment" but it will have the information that you need.
Q: Is this a multi-tenant environment shared by users from different companies?
The demo we showed was using a dedicated Jenkins Enterprise by CloudBees installation. CloudBees does provide a multi-tenanted DEV@cloud Jenkins service as part of our PaaS (Platform as a Service) - please see How It Works and Build and Integrate for an overview. Customers typically use dedicated, on-premise Jenkins installations with the Deployit plugin to manage more complex, multi-environment build/deploy jobs, but it is quite possible to integrate this with cloud-based Jenkins instances where that is appropriate.
Q: How would we go deploying PlayFramework 1.x apps running in container-less mode using Deployit?
Please see the following for more detail about building and deploying Play! Framework applications using Jenkins on the CloudBees PaaS: Creating a Play2 Application. If you are interested, there is ClickStart (a complete example project-in-a-box) showing how to build and deploy Play! Framework apps: just create a free CloudBees account (sign up for free here) and look for the ClickStarts menu at the top left when you log in.
Even though we were deploying to an application server in this example, that is certainly not a requirement of Deployit. You can simply include the application code as a folder artefact in your deployment package and associate it with an appropriate command to start/stop the application during the deployment.
Q: Can Deployit deploy to WebMethods servers?
Deployit is designed around an open plugin API that allows you to add deployment configuration and logic for pretty much any target system, including WebMethods, and has a plugin community to share these extensions. XebiaLabs currently does not provide an out-of-the-box plugin for WebMethods, though (see http://xebialabs.com/platform_support for details).
Q: What type of API's does Deployit provide? In other words, how much scripting would we need to write for deployment?
One of the areas in which Deployit provides value is through out-of-the-box deployment logic for many enterprise middleware stacks (see http://xebialabs.com/platform_support). If you’re deploying to these technologies you should not have to add any additional scripting.
Due to the flexibility of the plugin API, even extending Deployit to new platforms can be done with minimal configuration and/or scripting. Obviously, a better estimate of the effort would depend on more detailed knowledge of your environment and deployment scenarios.
Q: Is the promotion plugin part of standard Jenkins or part of Jenkins Enterprise?
The Promoted Builds plugin (Promoted Builds Plugin) is OSS and freely available.
Q: The Jenkins jobs that deploy, what can they deploy? A single file, a package, a suite of packages? Anything you configure?
Deployment packages can contain many different types of file, folder or archive artifacts as well as resource specifications such as datasources that are not linked to any file. Over 100 types are available out-of-the-box and, as you already guessed, you can of course extend this to add new types you define via the plugin API.
Q: Will Jenkins Create Manifest file do auto deploy in WebSphere?
Deployit can also handle deployment of applications and configuration to WebSphere, yes. As regards manifest creation, I assume you are referring to the EAR manifest and not a specific WebSphere feature such as Liberty Profiles.
The manifest file for your EARs can indeed also be auto-generated; this is done by your build tool such as Maven, however, rather than by Jenkins directly. Whether you are able to have your manifests auto-generated will thus depend on your build tool.
Q: Where were the build artifacts being stored in your demo? I didn't see a binary repository being utilized.
Please see the Jenkins Copy Artifact plugin, which enables you to store and copy artifacts between the workspaces of different build jobs. There are also a number of plugins that allow you to use 3rd party binary repository services (e.g. Artifactory)
In the demo, the initial build job was creating the deployment package (which is simply a ZIP file with additional metadata) and publishing it to Deployit’s internal repository. Deployit retrieves this package whenever it is promoted to the next environment.
You can store deployment packages in an artefact repository such as Nexus or Artifactory, or decide to store only the components (i.e. your EARs, WARs, configuration files etc.) in your repo and store the deployment package itself only in Deployit. In that case, you can even consider removing unused packages from Deployit’s internal repository since you can always recreate them based on the “gold standard” components in your artifact repository, if needed.
If you have further questions, please don't hesitate to contact us:
Andrew Phillips, VP Product Management