A recent comment on twitter made me realize that perhaps people don't realize how flexible we have made deployment from DEV@cloud/Jenkins to RUN@cloud.
The reality is that these are complementary and orthogonal features.
The deploy now feature first appears to users as the fancy icon on the far right of the main Jenkins page
That icon appears if and only if the last successful build has at least one archived .war artifact. It is a short-cut, and if you don't want it there you can disable the column that includes it.
The next place you see the icon appear is on the project level page, again if and only if the last successful build has at least one archived .war artifact.
The third place you will see the deploy now icon is on the actual build screen. For freestyle projects, the icon is directly on the build screen… but only if the build has at least one archived .war artifact.
With the Maven project type (you know the one I hate because I feel it does nasty and bold unmentionable things to Maven) you actually only get this icon on the module(s) that have at least one archived .war artifact.
Then you can automate deployment, for example you can use the Deploy to CloudBees action in the post-build actions:
Or you can use it in the Build actions:
And last but not least in any way what so ever, you can use it as a promotion step in the promoted builds plugin:
Which would I use? It all depends on my needs. If I have a simple project that which has good tests and basically can be deployed safely, I would go to the project configuration page and configure the deploy now defaults to deploy the app straight into production:
By turning on one-click deployment I ensure that the application deployment is just as easy as triggering a build. One example we have internally is our Jenkins Enterprise documentation site where the CI build deploys the documentation to a staging instance, and the Deploy Now button pushes the same application to our production instance.
Nice, simple, and easy to use.
If I have a more complex process, for example our Google AppEngine integration application, I set up a promotion process with different promotion steps representing the different phases of testing that the application needs to go through before we push the changes to the production instance cluster.
Another thing I should point out is that if you have multiple CloudBees accounts, you can use the fact that we use the credentials plugin to provide the credentials use for deployment.
So you can have one CloudBees account for developers, and a different CloudBees account for operations. You can even tie the credentials within a folder and then use our Role Based Access Control plugin to lock down permissions on the folder so that the "deploy to production" jobs can all use the production credentials but the job configuration is locked down to prevent abuse:
Lots of things you can do, lots of power. I guess the problem is deciding when each of the techniques is appropriate for you!
—Stephen Connolly
CloudBees
cloudbees.com
Stephen Connolly has nearly 20 years experience in software development. He is involved in a number of open source projects, including Jenkins . Stephen was one of the first non-Sun committers to the Jenkins project and developed the weather icons. Stephen lives in Dublin, Ireland - where the weather icons are particularly useful. Follow Stephen on Twitter and on his blog .