[MUSIC] Welcome to this lesson on OCI DevOps Service. Before we dive deeper, let's first define what is DevOps. DevOps is a combination of software developers referred to as Dev and operations referred to as Ops. So that's where the term DevOps come from. It is defined as a software engineering methodology, which aims to integrate the work of Devs, an operation team by facilitating a culture of collaboration and shared responsibility. As you can see on the graphic here, continuous integration and continuous delivery or deployment CI/CD, is a DevOps best practice. Now, what do these terms actually mean? So with continuous integration shown in blue on the screen here, planned code build and test. Frequent code changes are planned, built, tested and revised. These small changes are continuously integrated in the code repository. Small, frequent changes are easier to manage, as errors are small, seen early and less likely to conflict with other code merges. Now, CI/CD tools trigger automatically standardized build and test steps, that ensured the code changes being merged into the code repositories, are error free and work with existing code. So that's what really continuous integration is all about. Frequent small code changes, merge frequently, so you don't get into this kind of code and code marge hell, when you have a big code base to kind of marge, right. Then, there is this concept of continuous delivery and continuous deployment, so what does that mean? Once the main code branch passes unit integration, acceptance or any other kind of test, it is then released to production. In either an automated for fashion, which is referred to as continuous deployment because they're continuously deploying it. Or in a manual fashion, which is referred to as continuous delivery, and this is basically what is shown in green here release and deploys. It's either you deploy in an automated fashion, referred to as continuous deployment, or you do it in a manual fashion known as continuous delivery. Now, both these continuous delivery or deployment referred to a CD, is enabled through this notion of a deployment pipeline. Now code is built by a build server every time a change is committed to a code repo, and then it's tested by a number of different techniques and then it gets marked as releasable are deployable. So that's basically the idea, It CD basically leverages this thing called a deployment pipeline. You will hear this term referred to us again and again. So this is what DevOps looks like, the kind of the methodology and the key to DevOps is the notion of continuous integration, and continuous delivery and deployment, CI and CD. Now the OCI DevOps Service is basically a CI/CD platform for developers. And as we discussed in the previous slide, it automates delivery and deployment of software, or workloads to OCI platforms. They're different compute platforms, and why would you use this service? Well, using the service you can release features more frequently, with fewer errors and less downtime, as all the benefits we talked about in the previous slide. So how does the service really work in practice? Well, this diagram here best represents the OCI DevOps workflow. Right from committing the code, changes until its deployment to production environment. So kind of, you see this this kind of a workflow here. Now, the key components of the workflow are the build and the deployment pipeline. So the build pipelines, as we discussed earlier, this is regarding the CI continuous integration, and deployment pipelines are continuous delivery and continuous deployment. The CD portion right to the build and deployment, CI and CD. So this is kind of the manage, CI/CD platform. So, the first thing you start with is a code repository here. It's a best practice to track your code for your app, in a version control systems such as gate. So you start with that code repo, and then what happens is, you can manually trigger the bill stage, but it's usually triggered automatically when you commit your changes. So you can commit your code changes here. The build stage takes the code, fetches the required libraries and assets, and packages these into a self contained binary or container. The result of the build stage is a build artifact, as you can see here, in container registry and artifact registry. Now these build artifacts could be stored in a container registry, or an artifact registry, what is the difference? An artifact is a software package, library, zip file or any other type of file used for deploying application. What can be an example, well, python libraries would be an example of an artifact, so you store them in artifact registry. The rule of thumb is, any non container, non compute images or artifacts goes in the artifact registry. So zip files etcetera, libraries etcetera, and any darker image you would store in a container registry here. So that's basically, together they are kind of referred to as artifact repositories. And now once you do that, then basically the deployment pipeline contains a sequence of steps for deploying these artifacts. You take these artifacts and then you deploy them to target environments. And in case of CI, this could be a compute host, whether it's a virtual machine or a bare metal machine. It could be a managed kubernetes cluster or it could be a server less offering, like article functions, so you could actually deploy your code. So this is the complete workflow, as you can see it's a CI/CD platform. So you build your code here, and then you deploy your code and you do this in a very visual manner. So, the service gives you kind of a visual palette, where you can design how your build and deployment pipelines would look like. Now this is of course an foundational lessons will be not covering all the details, but hopefully this gives you a good overview of how the service works. Now, also one thing which we didn't cover is this service gives you a CI/CD platform, but service also has flexibility and it can also integrate with your existing CI/CD workflow. So if you have something running, it kind of facilitates that. So hopefully you found this lesson useful, thanks for your time.