This guide describes the upgrade process for CloudBees CI on traditional platforms. CloudBees recommends that you always upgrade to the latest version of your CloudBees product, ensuring wider lifecycle support coverage, plus more security patches added via the CloudBees Security Advisory, resolved issues, and new features.
|
CloudBees strongly recommends that you upgrade your CloudBees CI on traditional platforms instances that are not already running Java 11 as soon as possible. The ability to run new versions of the product on Java 8 will be removed in an upcoming future release. Releases that occurred during the support window for Java 8 will continue to run on Java 8. As a best practice, CloudBees recommends that you upgrade the operations center first. Then, you should upgrade any agents and controllers at the same time. If you use any customized pod templates in your environment, make sure they are also running Java 11. |
Choose an upgrade target
CloudBees supports upgrading your CloudBees CI instance to a version up to one year later than your current version, as documented in Upgrading between versions.
For this reason, upgrade your CloudBees CI environment on a regular basis. If your instance is more than a year old, multiple upgrades will be required to upgrade to the latest release.
If running versions older than 2.452.2.3 , follow the specific version guidance from Upgrading from CloudBees CI versions older than 2.452.2.3
|
Preparing for the upgrade
Before upgrading, CloudBees recommends that you complete the following steps to prepare for the upgrade.
Best practices when upgrading
When upgrading, CloudBees highly recommends the following best practices.
-
Change one thing at a time: Limit the changes you make to one area at a time. For example, do not plan to make infrastructure changes such as hardware upgrades, networking changes, or OS package upgrades when upgrading. This helps to identify and isolate the root cause of any issues you encounter.
-
Upgrade the instance where it is running: Upgrade your instance in the same location where it is currently running, even for production environments.
CloudBees does not recommend that you keep two different production instances running at the same time. This may be done to avoid downtime while performing the upgrade. However, unless you really know what you are doing, it is very difficult to replicate the exact same environment. For example:
-
The inbound agent does not work correctly as the
$JENKINS_URL
because the location is different. -
Credentials may fail if the secret is not the same for both instances.
-
The OS may not be configured in the same way. For example,
ulimit
. -
The CloudBees CI configuration may not be correctly replicated.
-
-
Upgrade the CAS plugin at the same time as the instance: If you are using the CAS plugin and upgrading to version 2.277.1.2 or later, do not upgrade it using the Plugin Manager. It must be upgraded at the same time as the instance. Once the service is stopped, you must download the CAS plugin and manually replace
$JENKINS_HOME/plugins/cas-plugin.jpi
. -
Stop using the Maven plugin: The Maven Integration plugin is not recommended because it is considered unreliable by the Jenkins Community. CloudBees recommends that you migrate jobs using the Maven Integration plugin to Pipeline Jobs using the Pipeline Maven Integration plugin. If you are able to migrate your jobs, please carefully read the Maven jobs and Java versions compatibility guide.
End-of-life announcement
CloudBees has determined that this plugin will be removed from the CloudBees Assurance Program (CAP) in late 2022. Notification will be provided prior to the removal of the plugin. Please contact CloudBees Support if you have any concerns or questions.
Generating a support bundle
Before upgrading, CloudBees recommends generating a support bundle. It can help you troubleshoot problems with the upgrade and determine which plugins were upgraded in the process.
Enabling the CloudBees Assurance Program
Before upgrading, CloudBees recommends that you enable the CloudBees Assurance Program (CAP) to ensure you are upgrading to plugin versions that are tested by CAP, to avoid plugin dependency issues and prevent incorrect versions from being installed.
To enable CAP and upgrade your plugins:
-
Navigate to
. -
Verify that Enroll this instance in the CloudBees Assurance Program is selected.
-
Verify that Allow automatic upgrades of plugins on restart is selected.
-
Select Save.
Backing up your instance
Before upgrading, CloudBees recommends taking regular backups of your $JENKINS_HOME
directory for the operations center and all controllers. The backups should be stored at an offsite location such as cloud storage or, at a minimum, on separate hardware from CloudBees CI.
To back up your instance:
-
Back up the operations center and all controllers. CloudBees recommends using the CloudBees Backup plugin to automate the backup process. For more information, refer to Configure backups using the CloudBees Backup plugin.
-
You can also perform a minimal backup by making a copy of your
$JENKINS_HOME
directory for the operations center and all controllers. If the$BUILD_DIRECTORY
is not located in the default location within the$JENKINS_HOME
directory, you must back it up as well. If something unexpected occurs, the rollback process is based on the backup of your instance. For more information, refer to Back up $JENKINS_HOME manually. -
Controllers that have the CloudBees Backup plugin 3.38 or later installed support the Restore job type. The operations center does not have a restore option, so to restore the operations center when using CloudBees CI, you can follow the steps for Restore backup files manually.
-
-
Test the backup to verify it is valid. The backup is used to recover from a failure if you encounter a severe issue during the production upgrade.
After an upgrade of the Jenkins core version or plugins, you cannot directly downgrade the war
file and plugins. The only way to roll back is to restore the$JENKINS_HOME
backup. -
Validate the integrity of the backup by extracting the backup to another filesystem and verifying the checksums using:
find $JENKINS_HOME -type f | sort | xargs md5sum >~/checksum.log.backup
Run this for both the live and backup data, and compare the
checksum.log.*
between the two.
Creating a test environment
Before upgrading, CloudBees recommends creating a separate test environment that has a similar setup as your production environment with representative jobs. This is ideally a full test environment with the operations center and client controllers and requires a test license
. If this is not feasible, using a test controller with representative jobs is sufficient.
If you are creating a test environment and require a license, please send the instance ID for your test instance to CloudBees Support, and CloudBees will send you a test instance license. While you are waiting for the permanent license, you can use the Request a trial license button in the CloudBees CI UI, as long as your instance has internet access and can connect to the CloudBees License Registry. |
Creating jobs on your test controller
Create jobs on your test controller that are representative of jobs on your production controller. This allows you to test the upgrade using the key plugins for your workflow and interactions with any external systems such as SCM tools, artifact repositories, bug trackers, and cloud automation. This test environment can also be useful after the upgrade to test the installation of new plugins.
It is a best practice to create jobs that are a subset of representative jobs on the test cluster. These dedicated jobs represent your production jobs, but without using real data. CloudBees recommends talking to your development groups to find jobs that cover the primary functionality, such as:
-
Testing your end-to-end complex Pipeline jobs.
-
Testing jobs that utilize critical plugins.
-
Running jobs that are part of integrations.
-
Running jobs that are for specific technologies.
To clone a production controller to a test controller, follow the steps from Migration Guide: CloudBees CI, specifically the section titled, Case B - Migrate Entire Jenkins Configuration, Including Jobs.
Running the test jobs
Once you have created the jobs, you can run them on your test controller.
To run test jobs:
-
Update the test configuration for some representative jobs, so they do not collide with your production jobs.
-
Run the test jobs to ensure they work correctly in the upgraded test instance. You must recreate credentials on your test instance.
Upgrading your plugins in the test environment
CloudBees recommends upgrading the plugins in your test environment. After upgrading the plugins, you can run tests to ensure the upgraded plugins are functioning as expected.
Installing the Health Advisor by CloudBees plugin to controllers
Before upgrading your controllers, CloudBees recommends installing the Health Advisor by CloudBees plugin, if it is not already installed. The Health Advisor by CloudBees automatically identifies issues that could impact the performance, stability, and security of your controllers. It also identifies potential issues due to known issues on your controllers. You are notified via email when a new problem is found and the email includes links to the solutions for the identified issues. For instructions, refer to Health Advisor by CloudBees plugin.
Installing the CloudBees Quiet Start plugin to controllers
Before upgrading, CloudBees recommends installing the CloudBees Quiet Start plugin, if it is not already installed. The Quiet Start plugin ensures that builds do not start automatically when the instance first comes online after the upgrade.
Upgrading the operations center and controllers
Once you have upgraded your test environment and verified it is functioning as expected, you can perform the upgrade in your production environment.
If you are using the High Availability (HA) feature, the general process for upgrading the HA operations center or any HA controller is:
|
To upgrade the operations center and controllers:
-
Enable Quiet Restart to ensure that builds do not start automatically when the instance first comes online after the upgrade. Navigate to
and select Stay in “quieting down” state when restarted. -
Verify all running builds are complete. Navigate to
and wait for any running builds to complete before you upgrade a controller. -
Take another backup of your instance.
-
Upgrade the plugins and restart your controller immediately before you start the upgrade process.
-
Visit the downloads page, select your desired distribution type, and complete the instructions:
Java WAR file
If your CloudBees CI instance is run with the command
java -jar cloudbees-core-cm.war
orjava -jar cloudbees-core-oc.war
, you can simply replace thejenkins.war
file with the latest version.Ubuntu/Debian
-
Operations center:
apt-get update && apt-get install cloudbees-core-oc
-
Controller:
apt-get update && apt-get install cloudbees-core-cm
Red Hat/CentOS
The CloudBees CI on traditional platforms RPM installation package requires systemd. The majority of Linux distributions have adopted systemd, but if you attempt to use the RPM package to install CloudBees CI on traditional platforms on a Linux distribution that does not support systemd, the installation will appear to be successful, however the service will not be able to start.
Beginning in CloudBees CI version 2.319.1.5, the
epel-release
package is required to upgrade CloudBees CI on traditional platforms using an RPM, however some CentOS distributions do not include it. For these CentOS distributions, run the following command before you begin the installation procedure:sudo yum install epel-release
.-
Operations center:
yum upgrade cloudbees-core-oc
-
Controller:
yum upgrade cloudbees-core-cm
RPM/YUM with High Availability (HA): The RPM package contains a post-installation script to ensure ownership on several files including
$JENKINS_HOME
. If HA is configured, I/O errors can occur. For example, when upgrading one node while another node is still running. For more information, refer to JENKINS-23273.To address this issue, you can skip this script by adding the property
JENKINS_INSTALL_SKIP_CHOWN="true"
under/etc/sysconfig/jenkins
.OpenSUSE/SUSE Linux
The CloudBees CI on traditional platforms RPM installation package requires systemd. The majority of Linux distributions have adopted systemd, but if you attempt to use the RPM package to install CloudBees CI on traditional platforms on a Linux distribution that does not support systemd, the installation will appear to be successful, however the service will not be able to start.
-
Operations center:
zypper install cloudbees-core-oc
-
Controller:
zypper install cloudbees-core-cm
Microsoft Windows
To upgrade on Microsoft Windows servers, a new
.zip
file must be downloaded from the downloads page and installed.Servlet container
Once a
.war
archive has been downloaded, follow the servlet container’s existing application deployment process.When using servlet containers, CloudBees CI sets the
$JENKINS_HOME
to the$APP_SERVER_USER/.jenkins/
folder. If the servlet container installation does not include write permissions to this folder for this user, which is sometimes done for security purposes, you must either grant appropriate permissions or override this setting by adding the-DJENKINS_HOME=$MY_JENKINSPATH
argument in your servlet container startup. Refer to the servlet container’s documentation for how to add startup arguments.Tomcat
Use environment variable
CATALINA_OPTS
to add:-
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
. -
-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
which is needed for the Blue Ocean plugin.
CloudBees recommends that you configure it in the script
$CATALINA_BASE/bin/setenv.sh
(Linux) or%CATALINA_BASE%\bin\setenv.bat
(Microsoft Windows) that you will create to customize your application server.Custom container installations
If you use a custom container, you can locate the
cloudbees-core-oc.war
orcloudbees-core-cm.war
file in the deploy directory of your container. For example,/usr/local/jboss/server/default/deploy/cloudbees-core-cm.war
is the location for a default JBoss installation. -
-
After your controllers are upgraded, you must manually upgrade the
agent.jar
file for any inbound agents that are not configured to upgrade theagent.jar
file automatically. For more information, refer to Windows agent offline or unable to connect.-
SSH-connected agents upgrade the
agent.jar
automatically. -
You can enable automatic upgrades for inbound agents by Upgrading Windows Service Wrapper.
-
-
Upgrade the plugins in your production environment again.
-
Now that you are running the latest version of CloudBees CI and your plugins have been upgraded, CloudBees recommends you enable actionable build notifications in GitHub, Bitbucket, and Slack. This generally takes a few minutes and provides enhanced notifications for your developers with no Pipeline changes required. For more information, refer to Enabling actionable build notifications in GitHub and Bitbucket and Setting up actionable build notifications in Slack.
-
Review articles in our Best Practices: CloudBees CI and apply changes accordingly.