 Some of you may remember the time companies failed to actually be agile. Instead, they were just using agile practices. But this isn't a unique situation. But the problem is that they missed the second agile principle. The principle number two in the Agia MetaFesto is working software. So the people on the front end did their piece, but they never had anything that worked. It actually happens every time you are facing the need for a cultural change. Definitely a bitter pill to swallow. DevOps is hardly an exception, as more and more companies adopt automation principles, but only a few manage to build a DevOps culture and a solid development practice behind it. Hi everyone, I'm Igor Pavlenko. I'm a quality assurance competence leader at Alpexo. In this video I will discuss the main stages of development in DevOps, how it works, at the organization level and which technologies are used for it. DevOps is an extension of agile, so it doesn't reinvent the wheel. Plan, code, test, deploy and monitor, you get the idea. But for now let's focus on development. A typical agile process requires developers to push the code to the server when it's finished. It's considered production ready when a set of tests confirms that the code passes quality tests, unit and integration tests, functional and regression testing, and meets all the acceptance criteria. Once the code is ready, the release managers and system administrators kick in to actually deploy it into the pre-production or production environment. They are in charge of calculating system requirements, mitigating the risks associated with the new code and monitoring the application performance. Back to DevOps. We know that DevOps aims to improve delivery speed and code quality. That's why we rely heavily on automation and try to push every production ready bit of code ASAP. What makes it possible? As you might remember from my previous video, DevOps is meant to break the silence between operations, including system administrators, with release managers and development. So developers take on some responsibilities from operations teams and deploy the code themselves. But you've heard that before. What else is new? A whole lot. Okay, after designing and planning the app or feature, an engineering team writes the code as they normally would in DevOps fashion. This is called continuous development, as developers are constantly supplied with feedback. Devs get feedback from the development and deployment areas as testing results, or the feedback comes from production monitoring in the form of say performance metrics. You also get user feedback from UX or acceptance testing. The concept of continuity applies to the feedback broadcasting, development and improvement of a product, according to business objectives. And of course, the same goes for continuous testing. DevOps is a cycle of granular events, so there is no specific time and place for each stage. But logically, you can apply automated tests once there is a portion of code to run on. We can use tools like runorex, selenium and test complete to write automated tests for each part of the system. So continuous testing is present at every stage of process, which means testing through the whole pipeline. For development, this can be unit integration or functional tests. For production, we can run A-B testing, blue green deployment or canary testing. Let's move on to the next pillar, continuous integration. The code is stored in a repository that allows for branch merging, versioning, backups and more. Quite a generic thing. The DevOps part of it assumes merging the code frequently in version control systems like Git. In a central repository, the code is run through build and test automation. In a nutshell, a build includes versioning, code quality analysis and all kinds of testing required to prove the code is bug free. The final stage of a build is when system compile the source code into executable files that can run in a production environment. This way you prepare the code for deployment. Some of the most popular tools used for continuous integration are Jenkins, Maven and Travis CI. But technology is not everything. The cultural trait of this stage is learning why you should merge frequently and how to do it. With the traditional approach, devs work in isolated branches and merge only when the feature is finished. CI, on the other hand, requires engineers to merge more often, which allows for proper build quality and faster deployment. This is done by setting quality gates. A quality gate is a programmed or process restriction that either makes the build pass or fail. The build fails if it doesn't get over some defined threshold. By blocking the buggy code, the gate forces devs to concentrate on the code quality and merge frequently. So, a continuous integration server will run automated tests, reveal errors in the early stages and alert developers about them. This repeats until the system shows a green light and the build can be completed successfully. Finally, the code is ready for production. In a traditional agile project deployment, managers and system administrators would have to approve the release first before it can be launched on production. In DevOps, the process of deployment is always automated and the approval regulations allow developers to make it on their own. These are the practices of continuous delivery and continuous deployment. Both concepts describe the automation of code pushing on production. The difference is that in continuous deployment, the pipeline deploys the code fully automatically. While in continuous delivery, a developer is in charge of making the final decision for scheduling the release. Here, we can also run tests on production. The infrastructure of the production environment may include several servers used for testing and deploying safely. For example, a blue-green deployment suggests creating two servers with identical production environments. One of those is used to roll updates and run AB, small tests, or performance testing. Once they are completed, the servers switch their roles. This ensures the team doesn't break anything after deployment. So, summing up, the continuous loop of DevOps follows a single logic of developing better code, running automated tests, integrating, and deploying once all quality gates are behind. The monitoring of code in production creates a hub of feedback available to developers at the very beginning, which makes it possible to continuously develop, improve, and deliver. But here we run into the topic of our next video – operations stages in DevOps. So, in the next video, we'll discuss how the operations part of the process is done in the whole pipeline. We'll talk about cultural and technical aspects of it. My name is Igor Pavlenko, and see you next time!