Welcome back! In this lecture, we'll provide a brief overview of DevOps and related practices. This lecture will provide us with our foundational concepts, which we will expand on in the following lectures. Okay, let's begin.

DevOps is a paradigm-shifting approach to creating software. It has in recent times become the defective method for building, testing, delivering, and managing software applications. The core idea that DevOps embodies is that both development and operation teams should work closely together throughout the entire software lifecycle. From the initial development, right through to the installation, running, and maintenance of the application. This is an important cultural shift that needs to be embraced for successful DevOps adoption. 

Automation is another important requirement for DevOps to succeed. Automation accelerates the build, test, and deployment processes. If some part of your software development lifecycle is time-intensive and/or error prime, then considering automating it. Automation practices such as continuous integration, continuous testing, and continuous delivery, need to be utilized. As we'll see later on in this course, each of these individual practices, provides an important automation service, which when combined together allows you to create build and deployment pipelines. Enabling you to orchestrate the entire end-to-end process of building, testing, and deploying software releases. If you're just starting out on your DevOps adoption journey, then consider starting with a pilot program of work. This will allow you to test the waters, and kick the tires so to speak. 

Identify and form a DevOps team that includes members from existing dev-testing operations teams. Pick a project that is not overly complex, yet is representative of other software projects. You'll use this Pilot Project to establish and test the right DevOps practices that work for you. And allow you to establish competencies, that the wider team can be educated on. When considering overall requirements to deliver the pilot program of work, start from the left and work to the right. Then, start with version control, and finish with an automated deployment. 

Let's go over some of the high-level DevOps requirements that you should practice in your pilot. One, ensure that your DevOps team is ready to work together and collaborate throughout the entire pilot. Two, establish from the outset a good and effective version control workflow. Having the right branching strategy in place will influence downstream build, test, and deployment processes. Three, introduce a continuous integration service for build and test automation. This will help increase the cadence and quality of your build and releases. Remember, automation is the key to your DevOps adoption. Four, leverage continuous delivery, to automate the release into production. Five, insure that your DevOps team is updated with continuous feedback regarding the current state. And Six, measure, rinse, and repeat. Measure the outcomes of your first iteration. And the next iteration, increase the levels of automation, and continue to reduce any dependence on manual involvement. Remember, this is guidance only. The whole point of using a pilot program is to allow you to assess and adapt your DevOps adoption to your own advantage. 

As already mentioned, you should measure your DevOps adoption continually to understand how effective it is. With measurements in place, you can fine-tune any aspect of your DevOps adoption. Perhaps more work is required on the cultural aspect of DevOps. For example, your teams may be still too disjointed. Perhaps there is room for more automation. Deployments are blocked while infrastructures are being manually created. Maybe the live application is exhibiting too many failures, suggesting that test automation needs to be beefed up. Understanding how and where to find true new DevOps adoption requires you to measure. Consider sampling any one, or all of the following DevOps matrix. Mean time to production. How long does it take for any newly committed source code to reach production? Deployment frequency. How often are releases deployed into production? Average lead time. How long does it take for a new feature to be developed, built, tested, and deployed into production? Deployment speed. How much time does it take to deploy a new release into production? Production failure rate. How often do failures occur in production? And, mean time to recover, or MTTR. How long does it take to recover from a failure? Measuring any number of these will allow you to show improvement over time, and have the evidence to support for the buy-in from the business and teams. 

Keep in mind, DevOps is not a technology, nor a product that can be purchased and installed. DevOps is a discipline, it takes time to master. There will be challenges along the way to overcome. Therefore, start small, and grow over time. A few guiding principles are: establish a pilot program of work one on which you can measure the effectiveness of your DevOps practices. During adoption, don't be afraid to experiment. Some things will improve your overall productivity, while others won't. DevOps does not have an End State, rather it seeks constant improvement, that should be continually applied. Ensure that you have the right stakeholders, from the business, onboard early. There you have buy-in from them. Seek to understand each group's perspectives and measures for success. 

In the coming lectures, we'll dive deeper into the concepts of continuous integration, continuous testing, continuous delivery, and deployment, and monitoring to ensure that you have a good understanding as to why each is important for your own adoption of DevOps. We put into practice the DevOps theory that we cover by providing a demonstration in which we use the Atlassian BitBucket software as a service offering. We'll use BitBucket to maintain our source code, and to also create our own build and deployment pipelines. The pipeline will start by compiling a simple react based web app, which is then containerized using Docker. We'll reach astute the resulting Docker image into DockerHub. The pipeline we use, Terraform, to provision an ECS Cluster with an AWS from the ground up. Terraform will launch an ECS service, which in turn will launch several Docker containers based on our custom Docker image. Finally, our pipeline will execute several gauntlt tests to ensure that the deployment is both stable and secure. The ECS service, which sits behind a publicly accessible application load balancer, will allow us to manually examine the end result, as if we were an end user. For extra benefit, we'll come figure out BitBucket source repository and pipeline to see notifications to our Slack DevOps team-engineering channel. This will demonstrate the importance and practice of DevOps. 

Okay, that concludes this basic introduction to DevOps and DevOps adoption. Go ahead and close this lecture, and we'll see you shortly in the next one.