Now as I mentioned in the requirements of the video the goal of this is for you to learn a few very important dev ops kind of components. The first of which is continuous integration and the second is analyzing a proper workflow between staging all the way through a production environment.

So this is a relatively straightforward type of deployment diagram we only have four nodes and then each of those nodes has just a few components. And the main reason is because I didn't want to add a lot of complexity in regards to designing the diagram I wanted you to focus on learning what some of these components represent. So I'll give you a description of how it works in devcamp.

So whenever I add a new feature or any other developers are working on the system decide to add a new feature to the system they do not just deploy to that. So if I make a few comments and then push up to the master branch then what happens is it goes straight into this continuous integration server. I do not skip straight to production because of a number of pretty important reasons. If I were to make some changes that would break the server then I want to know about that before users know about that. And so that is one of the most important parts of this CI system and that stands for continuous integration and that is that you can look at this almost like your first line of defense. So this is an automated tool.

There are a number of different providers out there code ship Travis CI there really are countless number of CI providers and they all work in a very similar fashion. I personally prefer code ship. I like that they give some nice flexibility with how I can control that server but really you can use any of them. So what happens is as soon as I push to the master branch of devcamp then all of that code gets wrapped up and it gets sent to the CI server it gets sent to code ship then that's the reason why we have version control is one of the components. And then the service app this is the set of configuration options that I have inside of the CI server. So this is going to run all of the Rspec tests it's going to run all of the database migrations it's going to perform all of those tasks and that is what we have here with this artifact where it's actually going to build the entire application. So assuming that everything works because what happens many times is I'll push something up or another developer will push something up and not realize that maybe we made a dependency version change that would break the entire system. The CI server typically will catch those problems. And so assuming that everything passes it builds the system and then it automatically deploys it. So I don't have to deploy the application at all. The CI servers in charge of that it deploys to staging.

Now there are a couple nodes here you have staging and pre-production. Originally, when I built out this diagram I built it modeling it after devcamp and devcamp has a CI server, a staging and then a production. But as I do with all of the different courses that I build. I always take what I've proposed to other developers and other engineers and I show it to them to see if they have any feedback or anything they feel could be a better solution. One of the engineers really recommended that we integrate this preproduction environment here and that's a reason why I listed it in the set of requirements not because you need to have it. Like I mentioned I do not have a pre-production environment but when I talked with a number of industry engineers they said that they work on applications that have that.

So I wanted to include this right here. There are some very similar types of elements between staging and pre-production and part of the reason why I personally did not create this type of environment for devcamp but what this typically does is you are going to push to the CI server then you're going to go to staging. Staging is where you make sure that everything is still on the page and everything is working and that nothing got passed by the CI server and you can check it out. Now once that is there this can initiate a copy to pre-production. So if you're working on a very large application and you have a dedicated QA team then this is where all of the QA developers are going to come in and they're going to test everything out. They're going to run even more tests than what we have in the server. Make sure that everything is working properly.

If it passes all the tests for staging pre-production and obviously on the CI side then it can finally be deployed to production. And so that is a pretty common type of deployment setup when it comes to modern applications. As I mentioned this pre-production stage this is optional but if you are working on a very large application you most likely will see something like this. It's part of the reason why I wanted to include it. But the most important component here is I wanted you to learn what a CI server is and how you can use it for not only running tests and those kinds of tools but you can also use that for actually deploying your system so that you personally as a developer are not having to interact with that type of deployment workflow.