Deliver Software More Quickly with Pipeline

Continuous delivery allows you to deliver software with lower risk. The path to continuous delivery starts by modeling the software delivery pipeline used within the organization and then focusing on the automation of it. Early, directed feedback, enabled by pipeline automation enables software delivery more quickly over traditional methods of delivery.¹ Jenkins is the Swiss army knife in the software delivery toolchain. Developers and operations (DevOps) personnel have different mindsets and use different tools to get their respective jobs done. Since Jenkins integrates with a huge variety of toolsets, it serves as the intersection point between development and operations teams. Organizations have been orchestrating pipelines with existing Jenkins plugins for several years. As the experience has deepened, organizations want to move beyond simple pipelines and chart complex flows to map to their specific delivery process. For Jenkins users, creating and managing complex pipelines just became easier. The new Pipeline plugin, contributed to the Jenkins open source project by CloudBees engineers and developed based on community requirements, provides the necessary infrastructure to capture and deliver these flows. This blog series gives an overview of the Pipeline feature now available in Jenkins. Readers will walk away with an understanding of how their delivery pipelines can be set up and delivered using the Pipeline feature. 

Continuous delivery is not pixie-dust that is sprinkled across the organization to magically crank out software! Continuous delivery is a process - rather than a tool - and requires a mindset and culture that has to percolate from the top-down within an organization. Once the organization has bought into the philosophy, next comes the hard part of mapping the flow of software as it makes its way from development to production. This flow crosses various departments with explicit intra-departmental handoffs. This is where the development and operations teams meet to get insight into what occurs on the other side of the world. More often than not, the teams find that each department is using Jenkins. Thus, Jenkins is chosen as the default engine that drives continuous delivery. There are additional factors that should be reviewed on the path to continuous delivery. These factors include componentizing the application under development, automating the entire pipeline (within reasonable limits) and freeing up contentious resources. ²

¹ A discussion on the business value of continuous delivery is available at http://pages.cloudbees.com/rs/cloudbees/images/Business-Value-ofContinuous-Delivery.pdf

² This article further discusses issues for consideration: Preparing for Continuous Delivery in the Enterprise, Andrew Phillips, August 28, 2013, InfoQ