 So now that we introduced the topic of continuous integration, continuous deployment and the outline, let's go a bit more in depth on these two concepts. So continuous integration and continuous deployment. Especially continuous integration should nowadays be state-of-the-art, state-of-practice. We are continuously pushing several times per day automated tests are run and ideally there's some kind of build that you could even deploy maybe. But what you need to get started there is first of all automated tests. So that's the absolute minimum. So without automated tests you can't regularly test the system in an automated fashion. So you need to be rather disciplined on writing unit tests that can be automated and push them in a regular manner. Now to do this regularly and to not break other people's code you usually also need to be quite disciplined about actual unit testing that you don't test the entire system because then if someone else changes something it's very likely that things might break in between. So this is something you'll need to start off with. Then you need the actual product, the actual solution that does the continuous integration so some kind of software system that is capable of realizing whenever someone pushes a new code is able to build it, is able to test it and then somehow publish the results. This started with tools like Jenkins, cruise control, where others. So solutions that you had to build yourself and run on your own server. Now there are services that you can use online, for example Travis CI is one of them but also repositories like GitLab or even GitHub are offering this nowadays. So it's not that complicated anymore to set up these kind of CI solutions. It used to be much, much harder. All of them have in common that you usually have for each project you have to have some kind of configuration management of what are the dependencies, how do you build it, how do you test it. So you somehow need to tell the tool what it should do and how it does it. Nowadays these often look like these kind of pipelines so you have something coming in that usually starts with the repository and then you have a number of tasks that happen after each other. For example you clean up directories where you're going to do the build, you check out the code from the repository, you install the dependencies, you build your test, you publish the results and you clean up for example. So very often they look similar. Now one thing you need and I've already mentioned it for the tests is some kind of discipline in your process. So it needs to be clear that automated tests need to be in place, everything needs to be tested, often maybe in a test-driven development fashion. You need to follow a certain Git or other revision management tool and a specific way of using that. So there are for example certain branching systems like GitFlow and Git that you can use so that you can tell your CI solution what exactly should be built. So that a single, if you change something as a developer you don't break everything but maybe there is a certain rule that whenever the feature that you are developing is complete you are going to push it onto the main master branch. Otherwise you're working on your own feature branch. So there are specific models for how you do them. I'll just mention GitFlow here but there are a number of them. So if your company is not using any of those it's just working in an undisciplined or ad hoc manner then maybe that's the first step to actually look into how do we follow a specific branching model, how do we do testing properly and then set up the continuous integration solution. So this is what you need and then finally again this is something I've mentioned but there is always more and more configuration management involved here. So a lot of scripts and configuration files that set how all of this works together. So where are the tests, which branch should we use, what kind of steps are there, how do we build the product and all of these kind of things. So it's getting more and more complicated and then you also need to keep in mind that most software products don't just have one main or master branch but you might have different versions that you need to support. These different versions might have different dependencies and so on. So this can get very complicated. Now let's move to continuous deployment. Additionally to integrating and having a build we also want to deploy directly and directly to the end user. And what does that mean? It means we don't only need automated tests, we also need in a way a good test suite. And what I mean by that is a test suite that is not only good on unit testing level but it really captures everything. You should have confidence in whatever the automated testing does is sufficient to show you whether it should be deployed. So you need to have integration tests, you need to have system tests, you maybe need some kind of automated acceptance tests that tell whether the requirements are fulfilled or not. So you are actually looking at a lot of different tests and additionally maybe things like fuzzing or penetration testing and security aspects, usability aspects. So the tests on an automated level should really show you yes, you can deploy or not. And in practice this is really difficult and this is maybe also the big milestone for companies to actually go towards continuous deployment that they don't necessarily trust this. So it's very common to have this sort of deploy button where the developers or the managers feel we can't really trust the tests suite completely. We want to have the system that it gets everything ready, the binaries or whatever we have is ready. There's just a single button that I need to push manually so that at least you have the control over it. You can maybe quickly look at the test results and then deploy but there are not many companies that would deploy directly. This depends heavily on your domain. Then of course we're talking about deployment. You actually need to have the option or the possibility to deploy. So if you for example think of something like Android, the Android ecosystem, Android phones, you can't deploy automatically to the user. The user always has to accept it first. The user has to update the app. This is different if you for example Facebook or Google, you're pushing something to the web. As you've pushed it, the users get the new version. But this is not always possible. There might of course be regulations. Maybe you have certified your software in a certain way and whenever you have a new version you need to go through some kind of audit then you can't just deploy. So this is in practice what is also limiting a lot of companies that they can actually not deploy because they have different circumstances that prevent this. But nowadays as we have a lot of web based systems that we can just push a new version, we can definitely use this quite well. Now what we move into next is assuming that we can just deploy a new version to the customers, to the end users, what can we actually do with that? That brings us to the topic of continuous experimentation next of essentially trying out different versions, different features with different parts of the users. So let's do that next.