can some one explain some steps how to upgrade Jenkins manually in production where server doesn't have any internet. what precautions do we need to take for production env before upgrading. How to manage plugins upgrade too if there is no internet
thanks....
So there are multiple options. Blue-Green, Regular Upgrade, Advance Test Upgrade
Blue-Green - Spin up another instance of Jenkins for the desired version. Copy plugins, jobs directories from PROD to new Instance of Jenkins. Verify the setup is working as expected. Apply any patches specific to version if required. E.G: Upgrade incompatible plugins specific to new Jenkins version. Test all types of Jobs. Finally Make the newly installed instance as PROD and make the existing as passive. You can repeat the same exercise in future and the passive becomes active in future. Infact you can put a Apache Reverse proxy infront of both instances, and make your Apache point to the desired instance for PROD.
Regular Upgrade - Inform all required and impacted parties. Take an approval for the downtime. Take the backup of you JENKINS_HOME. Make a note of Plugins that are incompatible in newer version of Jenkins. Upgrade to new version. Replace the incompatible plugins with supported version and finally test the jobs. Worst case if you are running out of time rollback to backup version.
Advance Test Upgrade - Copy the Jenkins_HOME. Install Jenkins new version on some other machine. Copy the jobs,workspace, plugins and config.xml. Verify the new instance is working. Make a note of things that you followed for the upgrade. Next take an approval for Downtime of PROD jenkins. Upgrade Jenkins based on the above steps.
Please comment if you need additional details specific to any of the above 3 options
Related
This is a not related to code fix, but a general approach for test automation.
I have a test automation written in javascript which runs perfectly on my machine as well as my local jenkins.
Now, i want to use my company's server(centOS) and jenkins so that it is accessible to everyone in my organization.
Issue: nodejs version in company's server need update to run my automation, but server team wont do it since they are not sure if any other functionality used be other teams may start to break because of the upgrade.
Have you faced this situation. Do you have different servers for core code and automation scripts. Please suggest.
This is a complex situation that really depends on many variables. I would recommend using an agent that contains the proper version of Nodejs. With this solution you can leave the current build server how it is but you can also use the exact version of node you need. This will require an extra server/VM with the Jenkins slave software but this will remove the need to change the master server.
The solution my company went with is using Jenkins 2.x with Declarative pipelines and ephemeral Docker containers for builds. This allows you to use any Docker image such as the official Node image. You can pin a version and build it with that. With this there is no need to worry about the version on the server. Jenkins Master doesn't even need to actually build.
Could you please let me know what precautions need to be taken while upgrading Jenkins from 1.631 to 1.651.3 other than config.xml of Jenkins and Jobs along with Plugins.
I have 'n' no# of jobs configuration and how to achieve the roll back.
It is recommended to check change-log from official site first, as people use different functions / plugins in different way. And you can install the new version in different host, to check your jobs before applying to production env.
I'm new to jenkins.
For that sake I installed the latest version of jenkins i.e. 1.632 on my ubuntu and deployed a war using post build actions in the configuration part. That worked fine for me.
Then I changed a few things in the build making sure that it fails when deployed and it effectively did and I'm not able to access the application die to deployment failure.
But I'm curious here, I have heard that in case of a build failure jenkins makes sure that the previous build remains deployed so that the application is always up and running. Please clarify if I'm wrong or doing anything wrong in my deployment steps.
I did searched a lot about this but couldn't find a valuable answer.
Haven't done much with the deploy plugin but it states this in the docs
Now when you trigger this job you can enter the build number (or use
any other available selector) to select which build to redeploy.
So you can set up a build on failure which will redeploy the last stable version. Here is also an example how to get the last stable build number:
http://<JENKINS>/job/<JOB_NAME>/lastStableBuild/buildNumber
We're building a continuous integration pipeline for the project I'm working on. We have a number of build artifacts (both JAR and WAR files) which we have versioned and deployed to an Artifactory server.
All our JARs start at version 0.0.1-SNAPSHOT. As we develop, we'd like to mark milestones by setting a particular point in the codebase as 0.0.1, and starting development on 0.0.2-SNAPSHOT. Eventually, a particular version will get accepted by QA, and promoted to 0.1.0, and we will start working on 0.1.1-SNAPSHOT. The same process will happen with a release to Production, when we reach 1.0.0.
I can't seem to find a plugin for Jenkins that supports this kind of versioning. Ideally, it would track the current version of each WAR and JAR, and once it hit a particular point (after running acceptance tests) it would automatically increment the version. Does such a thing exist?
You can make use of the gradle-release plugin. Please find different approaches that are documented here
I am on a redhat linux box. I recently updated Jenkins to version 1.509 only to find that after doing so it has "forgotten" two of my jobs/projects. The jobs can still be found on my Jenkins machine under /var/lib/jenkins/jobs, but they no longer show up in the Jenkins GUI. I attempted to re-create them based off the configuration file I have, but I am not confident I have totally re-created the functionality they had.
I also tried to copy the job and or rename it hoping that would get jenkins to see it, but no luck. I had tried cp -r /var/lib/jenkins/jobs/JOB1 /var/lib/jenkins/jobs/JOB2. I also restarted the service a number of times. Finally I updated all of my plugins on the off chance that was somehow related.
So my question is "How can I get Jenkins to notice these jobs?" or failing that "can I run these jobs from in the terminal?"
NOTE: I am not discouraging others from upgrading Jenkins. After I upgraded Jenkins did complain about a number of things which I didn't pay enough attention to which I believe got me into this mess in the first place.
If I were you, I would try the Jenkins CLI (from $JENKINS_URL/cli) and use the create-job command and feed the job configuration file to the cli's stdin.
If that does not help, I would inspect Jenkins log files (you are saving stdout and stderr of Jenkins somewhere, right?) for any errors or clues. If the job failed to load because of some tag that you can guess is provided by a plugin, try to remove that part from the config file.
If that does not help, I would upgrade Jenkins. I think there might be some fixes related to this in the LTS version changelog since 1.509.
And above all... if I were you, I would start making backups of the job configuration files.
I regularly back up the global config.xml, all the job config.xml files and all the plugins. Using these I can set up my Jenkins from scratch. And I do that to set up a test instance where I try any plugin or Jenkins core upgrade. If I see no problems after running a few of the trickiest builds, I know I can upgrade the production instance with much more confidence.