 My name is Itzy Gamble, and I'm going to show you how you can do continuous integration with GitLab. Continuous integration is a software development practice that encourages developers to integrate smaller code changes into a shared repository several times a day. Each check-in is then verified by an automated build allowing teams to detect problems early. CI enables releasing code more frequently, faster, and less risky. I will wear the hat of a software developer. I will create a new branch of code in GitLab repository. I am ready to update my code. This is the small change I want to make. I will commit a change and will create a new merge request for my change, so it would get verified and merged to the code base. My goal as a developer is to integrate my code as soon as possible, and if there is any issue with it, I would want to get notified as soon as possible so it would be easier for me to fix it. GitLab runs a CI pipeline on my branch for each commit, which builds a code and then runs automated test scripts as well as security, compliance, and code quality scans. GitLab has a native support for Docker. It builds a Docker image for my code and pushes it to the built-in registry. As a developer, I don't have to worry about local test environment. GitLab will deploy the Docker image it created via its native Kubernetes integration to a test environment. It saves me a ton of time. I will be notified via email on the build completion status, if it failed or passed. All test results, security and compliance scans will be shown in the merge request. Having all this info available for me in one place makes it easy to fix things if necessary or to collaborate with my peers on that. I will assign a reviewer that will review my code. Once my change is verified, I will merge the code to the main branch. I am done with this change. It is a great time for a coffee break. While drinking my coffee, I will wear the hat of a DevOps engineer. As a DevOps engineer, my job is to make sure GitLab CI is efficient, fast and scalable, and that there are no blockers avoiding the team doing their job, and this team moves fast. GitLab CI configuration is made via code in a YAML file. I love to work with YAMLs as they are human readable files which are easy to update and track. I will show you the .GitLab CI YAML file I created for our team. In this file, I added all build and test jobs. In our company, developers are allowed to change this configuration file as needed. This makes them happy and productive. They can add build steps and automations on their own. I can track all changes they do, date of changes and the other of them. In case of configuration issues, I can quickly detect issues and fix them immediately. GitLab runners are the actual build agents that run the build jobs. We have thousands of commits every day. My job is to make sure the team has available machines all times, so any developer will get fast feedback on his commits. Sometimes in minutes, instead of waiting in the pipeline queue for available build machines. Our runners run in autoscale mode, which creates on-demand runner machines. With autoscale runners, we always have resources available to satisfy the iLoad in our company. During low workloads periods, the autoscale runner removes the unnecessary resources. This saves us a lot of money. Jobs in GitLab run inside docker images. This eliminates compatibility issues in the build server and keeps them clean and secure. Okay, I have to leave now. It is the 22nd of the month. GitLab just released a new version with many features. I need to check this. See you soon. Bye. Today I have many hats. And now I will play the role of development team lead. My role is to make sure my team is able to deliver planned work and resolve any blockers. Let me show you a few tools I'm using. The CICD analytics helps me see the big picture and the team's productivity. It provides statistics such as overall pipeline and success ratio. The value stream analytics shows me the time it took to complete different stages in the development process. This helps me to identify button lengths and address them. We deliver valuable features to customer fast, but we need to ensure that the team does not introduce risk in the new code they are reading. The security and compliance dashboard helps me monitor risks in each of our projects, so we will not release vulnerable code. Hope you enjoyed this demo. Let's continue learning GitLab CI. See you soon again at my next demos. Bye.