CODEWITHSUNDEEP
buildjenkinscontinuous-integrationrelease-management
Sujith
Sujith

Reputation: 307

How could I automate build deploy in jenkins?

We are using jenkins for CI. we get late night builds. Is there any way to automate the build deploy as soon as we get a mail or intimation ? Any suggestions would be appreciated..

Upvotes: 8

Views: 38923

Answers (3)

Bheem Singh
Bheem Singh

Reputation: 697

In tomcat, configuration with jenkins and tomcat:

  • Install and download the jenkins on your server and start the server go to jenkins portal after that create the project using 'New Item' and select the pom.xml and create the maven project.
  • Now go to your project and click on Configure and select the "Restrict where this project can be run" and add master in your Level Expression.
  • select the "Source Code Management" clisck on git and configure your git repository and credential and branch name.
  • Select the "Build" add Root pom : pom.xml and Goals and options : clean install -DskipTests
  • select the "Post-build Actions" and select the "Deploy war/ear to a container"
  • WAR/EAR files : target/test.war
  • Context path : test
  • Containers select tomcat and add Credentials
  • Tomcat URL : example : http://localhost:8080/

Update the 'apache-tomcat-8.5.5\webapps\manager\META-INF\context.xlm file. uncomment the Value tag. and restart server

context.xml file

Before : 

<Context antiResourceLocking="false" privileged="true">
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
     allow="192\.168\.0\.9|127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
</Context>

After change :

<Context antiResourceLocking="false" privileged="true" >
</Context>

for auto deployment: go to 'apache-tomcat-8.5.5\conf\context.xml' and add antiResourceLocking="true" in 'Context' tag

Upvotes: 0

Iker Aguayo
Iker Aguayo

Reputation: 4115

These are the ways I know:

  • With a script:

In the Jenkins configurations, you can execute windows/shell commands after the execution of your maven goals. In my case, I have a Glassfish on a Linux, and via ssh I execute the asadmin parameters for the deployment. I have installed an instance in the server, and the process that I follow is: stop instance, undeploy app, deploy app, start instance (commands).

  • With a Maven Deploy Plugin:

This plugin takes a war/ear file and deploys that to a running remote application server at the end of a build. The list of currently supported containers include:

Tomcat 4.x/5.x/6.x/7.x JBoss 3.x/4.x Glassfish 2.x/3.x

https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin

  • With Cargo:

The Deploy Plugin is based on this. You must edit your pom.xml and execute the goals of deploy with maven.

http://cargo.codehaus.org/

Upvotes: 1

gaige
gaige

Reputation: 17471

One mechanism to deploy off of a build on Jenkins is to use artifacts to place the latest binary in a known location, and then kick off a new job (only on success of the compile/test phase) which uses (private key protected) ssh or scp to copy the artifacts to the test/production machine and then perform the install.

We use a similar mechanism for some automated testing that we do. The tricky part is getting the shell command to handle the ssh keys, so we do the following:

eval `ssh-agent -s`
ssh-add ~/.ssh/your_private_key_here

As long as that private key is on the Jenkins server and the public key is on the server you're trying to push to, you can then use ssh and scp commands in the rest of the script to perform functions on the server in question.

If you prefer to run the process entirely from the target server end, you can create a small script that runs on the server that checks for new files in the artifact directory of your Jenkins server build. Thanks to the latest path, you don't have to know the build number to do this. To find the specific path, you can log in to your Jenkins server (once you've saved at least one artifact), and find the project you are using and look at the Last Successful Artifacts, which will be URLs to the last successful builds of the artifacts. These URLs remain constant and always point at the most recent successful build, so you don't have to worry about them changing unless the project name or server name changes.

NOTE: there are security holes here that you can drive a truck through if you are doing this for anything other than a deployment to test. In the case of the first mechanism, your build server has an ssh key that gives it access (potentially destructive) to the target. In the case of the second mechanism, you are trusting that the Jenkins server will only serve up binaries that are good for you. However, for test environments, push to stage, etc. these techniques will work well.

Upvotes: 4

Related Questions