Continuous Integration Workflow

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.