CloudBees Jenkins Enterprise provides Managed Masters "as-a-service" on most public and private cloud providers, which helps organizations scale continuous integration and continuous delivery (CI/CD). CloudBees Jenkins Team, on the other hand, provides a single-instance option that allows small independent teams to implement continuous integration and delivery.
While CloudBees Jenkins Enterprise works best for large-scale installations and CloudBees Jenkins Team is designed for smaller-scale installations, both products include the verified integrations and worry-free upgrades enabled and monitored through Beekeeper Upgrade Assistant and provided by the CloudBees Assurance Program. Tabs in the Beekeeper Upgrade Assistant interface show which plugins have been updated, which plugins are available for your environment, and which plugins you already have installed.
CloudBees Jenkins Team provides a stable Jenkins distribution, verified (curated) plugins, and expert assistance. It can run as a stand-alone Java process installed manually for your operating system, in a pre-configured Docker image, or within a cloud-based AWS (Amazon Web Service) or Azure infrastructure. If you want to migrate from a CloudBees Jenkins Enterprise .WAR file to CloudBees Jenkins Team, doing so is largely a matter of removing the license.xml file in your JENKINS_HOME, disabling any unlicensed plugins, and restarting Jenkins.
This guide is designed for instance administrators who want to continuously build, test, and deliver applications with their new Managed Master or CloudBees Jenkins Team instance.
Teams that want to continuously build, test, and deploy their applications can use pipelines to automate these processes and integrate with their team’s tools. Users new to pipelines can begin by following a simple tutorial to set up a basic builds pipeline. For most teams, simply adapting this example flow will be sufficient to build their applications.
For more complex pipelines, and to configure integrations with your teams’ SCM, testing, and deployment tools, teams will first need to study the pipeline syntax to figure out how to declare their desired flow and build steps. Project administrators can then install the appropriate pipeline plugin to make the build steps that their teams need available for pipeline scripts.
To perform tests and create an audit trail for artifacts, configure a post section and use the archive step in the pipeline to encompass any test-related steps, track and archive test results, and archive artifacts.
Most teams will be able to leverage the most common deployment pattern for their applications - extending the number of stages in their pipeline to capture additional deployment environments, like "staging" or "production”, and triggering a shell script that orchestrates the details of the actual deployment.
Online version published by CloudBees, Inc.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
Apache, Apache Ant, Apache Maven, Ant and Maven are trademarks of The Apache Software Foundation. Used with permission. No endorsement by The Apache Software Foundation is implied by the use of these marks.
Other names may be trademarks of their respective owners. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and CloudBees was aware of a trademark claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.