Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m

Next lesson playing in 5 seconds


Free Preview: Continuous Integration Workflow


  • Overview
  • Transcript

Continuous integration is a development practice that requires code to be built and tested multiple times a day, whenever a new feature is committed by a developer. By integrating continuously, teams are able to detect errors quickly and track down bugs more easily. Many development teams find that continuous integration is crucial to their productivity.

In this course, Envato Tuts+ instructor Markus Mühlberger will teach you the concepts of continuous integration. You'll learn how to develop new features for an app using either of two very popular software development workflows, Git Flow and GitHub Flow. You'll also learn how to use both Travis CI and Codeship continuous integration servers, and you'll see the differences between them. You'll learn how to use continuous delivery from these services to deploy code to Engine Yard Cloud and Heroku. As a bonus, you'll also find out how to set up your own Jenkins CI server and use it to deploy a Rails app to a VPS with Capistrano.

1. Introduction

1.1 Introduction

Hi, and welcome to Continuous Integration Workflow. My name is Markus Muhlberger, and in this course I will teach you how to use continuous integration services to automatically test your code, and deploy your application to the cloud. The course is designed to show you different development approaches, and different providers to get you and your team started for modern software development. I'm going to use a Rails project as our example, but the workflows I show can be applied to almost any kind of software. We will be using two different development approaches, GitFlow and GitHub Flow, and the popular continuous integration services Travis CI and Codeship to test and build our application and also to apply it to the cloud. Specifically on Engine Yard and Heroku. I'll also show you how to set up Jenkins, an open source CI server and use it to deploy or raise application to a VPS on DigitalOcean. Sounds interesting? Let's get started.

1.2 What Is Continuous Integration?

Hi, welcome to our first lesson of the continuous integration workflow course. Before we can dig into code and tools, we need to know what continuous integration and continuous delivery is. That will be the agenda for this lesson. Continuous integration emerged from the development concept called extreme programming in the 90's. It advocated integrating several times a day, something that wasn't common in the old days. If there was an automated build system there were only madly builds, which means that the server running a build once a day at 2 a.m. And when you came into the office the next morning, you'd see if the build succeeded or not. Then the bug fixing begin. Nowadays, every push to a repository normally triggers a build on the server, with a hundred or more integrations every day. Now back to the concept of continuous Integration. When working on a shared code base, everyone is creating a different feature. And sometimes the implementation of those features don't play well together. This can happen due to different approaches to tackle the problem which is shared between multiple features. Or even a small thing like the different naming of method or class. Continuous integration aims to prevent this so called integration hell. By using a build server and automated tests, to test tiny changes to the code. Single commits or pushes to the repository. Even when the feature isn't yet completed. To be able to also test the feature against the current master branch, which might have come forward after starting. Developers should regularly merge master into their development branch to ensure compatibility before the feature is fully completed. And to be able to adapt in small steps. Since the build server takes care of testing, developers don't have to manually verify everything works. If the code base is well covered with tests. Continuous delivery extends continuous integration by not only running automated tests. It also takes care so that the software is in a state that is deployable to the user at any time. In case of a software product or a mobile application, this would mean that after all tests pass, the software will be compiled, installers will be created, and other assets will be prepared. In case of a web application, this can go so far that the software will be deployed to the servers automatically. For instance, either to a designated test environment or directly onto the production servers. Running necessary migrations and compiling static assets like stylesheets or JavaScript. Such a delivery process is called the deployment pipeline. Normally, you have multiple of those. Using the example from before, you could have a pipeline where the master branch gets deployed to a test environment and another one for a production branch after QA merges the changes from testing, gets deployed to the production environment, and different other services get triggered or will be notified about this deployment. Some companies like get app have a delivery process that allows them to deploy a feature to a single server in their production environment to ensure the roll out won't cause any issues. This isn't completely automatic. It has to be triggered by developer but the build server will run the tests before and the deployment by to this approach will be used. As you can see continuous integration and continuous delivery especially can be very different depending on your very special use case. But this isn't always the case. Within production and broad use of web frameworks the delivery process is similar every time. Companies like Travis CI and Codeship use this fact to provide a simple interface to the not so simple configuration of build servers. That is all for this lesson. I'll see you in the next one where we are going to talk about the two development reproaches, getflow and getupflow. See you there.