Book Image

Continuous Integration, Delivery, and Deployment

By : Sander Rossel
Book Image

Continuous Integration, Delivery, and Deployment

By: Sander Rossel

Overview of this book

The challenge faced by many teams while implementing Continuous Deployment is that it requires the use of many tools and processes that all work together. Learning and implementing all these tools (correctly) takes a lot of time and effort, leading people to wonder whether it's really worth it. This book sets up a project to show you the different steps, processes, and tools in Continuous Deployment and the actual problems they solve. We start by introducing Continuous Integration (CI), deployment, and delivery as well as providing an overview of the tools used in CI. You'll then create a web app and see how Git can be used in a CI environment. Moving on, you'll explore unit testing using Jasmine and browser testing using Karma and Selenium for your app. You'll also find out how to automate tasks using Gulp and Jenkins. Next, you'll get acquainted with database integration for different platforms, such as MongoDB and PostgreSQL. Finally, you'll set up different Jenkins jobs to integrate with Node.js and C# projects, and Jenkins pipelines to make branching easier. By the end of the book, you'll have implemented Continuous Delivery and deployment from scratch.
Table of Contents (15 chapters)

Build triggers

Whenever we push code changes to Git, we want our Jenkins project to start as soon as possible. After all, the sooner we know something is broke, the easier it is for us to fix it. You have probably already seen the Build Triggers section in the configuration of your Jenkins project. There are four build triggers currently available to us.

First, we can build the project remotely, which we will not do. Second, we can build after other projects, which is handy when you have multiple projects that depend on each other. Next is the periodic build, which should speak for itself. And last, we have the poll SCM option, which polls your SCM-in our case Git-for changes and triggers a build when something changed.

For now, we will look at the periodic build and the poll SCM triggers. Both use cron syntax (cron comes from the Greek word for time, chronos), which I find rather...