JBoss Command-line Deploy/Undeploy

I was creating a Chef cookbook to deploy a .war file to JBoss AS 7.1. One iteration of refactoring had me using the command-line tools provided with JBoss to do the deploy/undeploy. Ultimately, I didn't use this method, but wanted to document it in case I change my mind later.

I am using Bryan Berry's JBoss cookbook to configure my base JBoss install, which installs JBoss to /usr/local/jboss. I am also using the full-ha profile for the standalone JBoss configuration.

Variables

• CONTROLLER: the IP address bound to JBoss. I used Vagrant in this example, so the IP is an arbitrary static IP address that I chose, e.g. 33.33.33.11
• USER: the user to connect to the JBoss controller (you set this up with the add-user.sh script in JBOSS_HOME/bin)
• PASSWORD: the password to connect to the JBoss controller with

Deploy

The jboss-cli.sh script allows you to run in non-interactive mode. You must pass the JBoss commands along the command line as an argument, but if you have spaces in your command, then you have to put your commands in a file and use the --file switch to indicate the file containing your commands.

Here is a sample file, e.g. /tmp/jboss-deploy-command (should be one command per line):

/deployment=MyWebApp.war:add(runtime-name="MyWebApp.war",content=[{"path"=>"/path/to/MyWebApp.war","archive"=>false}],enabled=true)

In my example, I'm deploying an expanded archive as a directory, so the "archive" => false attribute must be present.

The command to execute for deploying MyWebApp.war is:

$ /usr/local/jboss/default/bin/jboss-cli.sh --controller=${CONTROLLER}:9999 --connect --user=${USER} --password=${PASSWORD} --file=/tmp/jboss-deploy-command

If all goes well, you will see this output:

{"outcome" => "success"}

Undeploy

Removing the web app is simple:

$ /usr/local/jboss/default/bin/jboss-cli.sh --controller=${CONTROLLER}:9999 --connect --user=${USER} --password=${PASSWORD} --command=/deployment=MyWebApp.war:remove

See also: https://community.jboss.org/message/630853.

Why I Love Go

I was just reflecting a bit on why I like Go (from ThoughtWorks Studios). I had previously been using Jenkins (which I love), and while I still love Jenkins and would happily use it again, here are some of the reasons why Go wins in my book for trying to do continuous delivery.

Recently, Dan Gilmer spoke at ChefConf about how Ancestry.com uses Go and Chef for continuous delivery. Prior to leaving Ancestry.com, I helped pioneer the early use of Go and Chef as an Agile coach for the development teams. Here is Dan's talk:

What I Love About Go

Workflow visualization. I love the idea of separating build pipelines from deploy pipelines, each with their mini-workflows. When I was coaching teams at Ancestry, I always taught them to identify their own business process and then document that as a pipeline and value stream map. The "pipeline" entity in Go is powerful for communicating to developers and product owners the business process they are using. I love the transparency. The caveat though, is that you have to mature as a team to find out the appropriate boundary of what belongs in your build scripts (ant, maven, etc.) versus the tasks of your pipeline stages.

Pipeline groups. I don't use these at Premier Fitness Camp because I'm using the community edition. However, at Ancestry, I loved being able to group pipelines per team and put security on them. Plus, in harmony with my statements above, the group of pipelines represents a boundary around all the business processes a team must use to release its software.

Environments. We didn't mature at Ancestry to my vision of using Environments before I left, but I did really like how the Environments view let you see what version was deployed via a given pipeline. I thought that was very powerful. With the use of configuration management (like Chef) knowledge about environment configuration, including application version, may not be as useful in Go. However, go makes it very transparent which version is in an environment. As long as you model your pipeline label template correctly, and put the right agents in the right place, this could be cool.

If I had the enterprise edition, plus a few remote agents, I'd probably use the Environments view a lot. Currently, I have modeled my deploy pipeline so that it triggers Chef to do the deployment on my remote servers. The pipeline version number matches the produced artifact number and Chef fetches the artifact from Go, so I know from looking at my pipeline group what version is out on a server, even without the Environments view.

Replay a version in the past or replay a failed stage. I love the ability to replay a failed stage in the middle of a pipeline without starting over. I know you can do this with Jenkins because you can just play a job. With Jenkins though, I get the feeling that I'm starting something from scratch rather than picking up the context of the overall pipeline.

What I Miss from Jenkins

Code coverage charts. Jenkins had a plugin for visualizing historical code coverage. In Go, I have to produce these on my own (since a plugin community/capability exists yet) and embed them in as an artifact and a custom tab.

Unit test trending charts. Same as code coverage charts above.