A while back I wrote about achieving continuous deployment with one-click deployments. I didn’t provide an example for that post as I mostly wrote about why you need to achieve continuous deployment. Here I will follow up with a simple example of how you can achieve continuous deployment.
Continuous deployment is quite easy to setup if you are using a typical Maven project structure and Bamboo as your continuous integration tool. Also I am assuming that you want to deploy your application to a tomcat server.
In your pom.xml file add the following configuration so that you use the Tomcat plugin for deploying your application to http://hostname.com/app. Change the path, url, and server configurations to suit your needs.
Also make sure that your .m2/settings.xml file contains the following for authenticating with the Tomcat manager.
In Bamboo create a new pan for your project. I tend to give this plan the name “Promote to Production”. Configure the Builder goal for Maven to run clean tomcat:redeploy. I also only allow a specific user to trigger this plan so that not everyone has permission to deploy into production. Finally, configure the build strategy to run manually, so an authorised person can click on the Build plan button in Bamboo to deploy the application.
Once set up the above instructions will allow an authorised person in Bamboo to click on a single button to deploy into production. Leveraging your continuous integration tool for deployment allows you to archive deployment artifacts such as your WAR files in the case where you have to revert to a previous version.
My most recent consulting gig brought me back into contact again with Maven. I have this love-hate relationship with Maven. I love using Maven for simple projects, that generally have only a development environment, and I hate using Maven for more complex projects where you have to create profiles for multiple testing environments. Maven is just too restrictive for the latter case.
If you have your own internal Maven repository setup and you want to deploy reusable modules to it then follow these instructions. It took me a while to figure them out as there is something wrong with Wagon’s internal ssh implementation. Using an external scp tool will save you a lot of grief.
1. Setup your local .m2/settings.xml as follows:
<privateKey>location of your ssh private key</privateKey>
You’ll need to create an ssh key. And provide a reference to your private key using the
element. This is simple to do in OS X, or linux, and can be done by running ssh-keygen. If you use Windoze then you’ll have to use Putty.
2. Log into your server hosting your maven repository and add the contents of your public key (id_rsa.pub) at the bottom of the authorized_keys2 file. You should create a generic maven user that everyone on your team can log into, this is because when you deploy your module it will be written to the filesystem with read/write permissions only for that user. Exit your server.
3. Go to your project and add the following to your project’s pom.
<name>Internal Maven Repository</name>
4. Run mvn deploy.
5. You should now see your project deployed to the maven repository on your server.