 Hi, I'm Cesar Saavedra, Technical Marketing Manager at GitLab. In this video, I'm going to show you how GitLab can help you make your releases safe, low-risk, worry-free, consistent, and repeatable. Rachel, a release manager, has been with her organization for over a decade. They have been arduously working on modernizing their release process by adopting continuous delivery best practices in an incremental fashion. She remembers the time when they used to schedule releases on weekends. On one occasion, they worked all weekend to roll out an update to their messaging backbone that they ended up rolling back. Back then, deployments and rollbacks were complex. Release planning took months, with cumbersome processes that required a variety of disjointed tools for source code management, ticket tracking, planning and work assignments, and communication, making rolling back oftentimes as risky as rolling out. Let's see how continuous delivery principles and best practices have been helping Rachel's organization with this type of situation and how GitLab can help. As part of a first incremental step into adopting continuous delivery principles and best practices, developers work on issues, stakeholders collaborate on merge requests, and at a predetermined point in time, Rachel declares a freeze and cuts the release. All these activities are supported and take place in a single platform, GitLab. Issues where product problems or new features are described, and merge requests where solutions are developed, are key inputs to the release planning process. As components of the release, issues and MRs provide Rachel the auditability and tracking of application changes done by the collaboration of DevOps engineers, system administrators and developers. Rachel creates a milestone that will be associated with the first release of their PROD MGR Spring project, and associates to it all the issues that the release will comprise. To track groups of issues with the same theme, she creates two epics, one for the UI related issues and one for the server side issues. She assigns the UI related issues to the front end work epic and the server side issues to the back end work epic. Since Rachel's organization is adopting agile methodologies, she also creates two weak development sprints. She first creates two consecutive iterations or sprints within the milestone timeline and proceeds to assign the corresponding issues to each. She can track the sprints through their detailed pages, which include many progress metrics. As she assembles epics, milestones and iterations, she can also visually track the release progress via the roadmap page, which helps to streamline the release process. Rachel's organization is transitioning to continuous delivery practices and she still needs to set a deploy-freeze window to temporarily halt automated deployments to production. This prevents unintended production releases during a period of time to help reduce uncertainty and risk of unscheduled outages. In addition, as part of the release approval gates, Rachel can protect the production environment by specifying who is allowed to deploy to it. Specific role and responsibility assignments streamline the approval gates and release process. At the appropriate time, Rachel creates a release, which automatically generates the release evidence, and she associates the release with the V1.0 RC1 milestone. This streamline process helps Rachel reduce the release cycle times. As a second incremental step into adopting continuous delivery principles and practices, every change is automatically deployed to the user acceptance testing environment, or staging, with a manual deployment to production. In this scenario, there is no need for a deploy-freeze and Rachel, the release manager, can cut a release from staging at any point in time. This sets up Rachel's organization for continuous delivery. To get started quickly, Rachel takes advantage of GitLab Auto DevOps capabilities, which help her to automatically create the release pipeline and relieve her from manually spending time creating her own pipeline. As a part of Auto DevOps, she can automatically deploy to staging and manually deploy to production as well as enable canary deployments. Auto DevOps, which is based on best practices, helps Rachel streamline the release process. The first job in Auto DevOps is the build job, which applies the appropriate build strategy to create a Docker image of the application and stores it in the built-in Docker registry. Faster and more reliable releases happen when you have build components, like Docker images, that are readily available to the release process in a uniform and consistent manner. Although the build stage is used in the Maven central repository, Rachel could have leveraged the built-in package registry instead. Rachel has the ability to visualize what specific features will go into production via review apps. As updates are made to the application via merge requests, they kick off review apps, which streamline the review process, including the automatic creation and destruction of an ephemeral review environment on which stakeholders can verify the updates to the application before they emerge to the mainline. Review apps help increase code quality, reducing the risk of unexpected production outages. Once the application has been built and passed many automated tests, checks and verifications, the Auto DevOps pipeline automatically stands up the staging environment and deploys the application to it. At this point, Rachel manually deploys the updated application as a canary deployment to the production environment. By doing this, she ships features to only a portion of the pod's fleet and watches their behavior as a percentage of the user-based visits the temporarily deployed feature. Before it works well, she can deploy the feature to production knowing that it won't cause any problems. Rachel then proceeds to start rolling out the canary deployment to 50% of the production pods. Incremental rollouts lower the risk of production outages, delivering a better user experience and customer satisfaction. Advanced deployment techniques like canary, incremental, and blue-green also improve development and delivery efficiency, streamlining the release process. To check the running application for integrity, Rachel clicks on the Open Live Environment button. She notices that her attempt to log into the application fails, so she decides to perform a rollback. She drills down into the production environment page and identifies the release that had been successfully running before she performed the last deployment. This page is an auditable sequence of changes that have been applied to the production environment. She clicks on the rollback button to start the rollback process. Rollbacks speed up recovery of production in case of failures, lowering outage times, and leading to better customer satisfaction and user experience. Pipelines usually run automatically. However, Rachel would like to schedule the execution of a pipeline once a day at midnight so that staging can have the most recent version of the application on a daily basis. To do this, she goes to CICD schedules and creates a new schedule. Scheduling pipelines can improve the efficiency of the development lifecycle and release processes. While the application is running in production, Rachel would like to understand how the release is performing and quickly identify and troubleshoot any production issues. There are a few ways she can do this. One way is to access the monitoring feature for a specific environment to track system and application metrics, such as system and pod memory usage and number of cores used. The monitoring tracking includes markers when updates were introduced to the environment so that fluctuations in the metrics can be correlated to a specific update. Monitoring reduces the time to identify, resolve and preempt production problems lowering the risk of unscheduled outages. It also provides an opportunity to do business activity monitoring and optimize cloud costs. Not only is this type of monitoring useful to release managers, but also to DevOps engineers, application operators and platform engineers. Another way Rachel can monitor the release is by creating alerts to detect out of range metrics, which are visible on the overall operations metrics dashboard as well as on each specific environment window. Alerts can also automatically trigger chat ops and email messages to appropriate individuals or groups. Rachel can manage alerts from the operations alerts window, a single location from which she can assess and handle alerts, which may include the manual or automatic rollback of a release. In addition, Rachel can track and monitor the release progress through Value Stream Analytics, where she can check her project or group statistics over time and see how her team improves in the number of new issues, commits, deploys and deployment frequency. Value Stream Analytics is useful in order to quickly determine the velocity of a given project. She points to bottlenecks in the development process, enabling management to uncover triage and identify the root cause of the slowdowns in the software development life cycle. Lastly, another way for Rachel to track and monitor the release is through Pipeline Analytics. Pipeline Analytics shows the history of your pipeline successes and failures, as well as how long each pipeline ran to help you understand the health of your projects and their continuous delivery. Rachel oversees more than one release, so she decides to update her operations dashboard by adding this project to it. Through this dashboard, she gets a summary of each project's operational health, including pipeline and alert status. Similar to the operations dashboard, she can also access the environments dashboard, which provides a cross-project environment-based view that lets her see the big picture of what is going on in each environment. Or she can drill down into a specific environment to get all the updates that have been applied to it. All these dashboards provide Rachel with the operations insights that she needs to understand how the release is performing in production and quickly identify and troubleshoot any production issues. As a third incremental step into adopting continuous delivery principles and practices, all changes go to production. This is also known as continuous deployment. Modifications to the application are immediately rolled out to production after passing many checks and validations via the CD pipeline. Rachel would like to exercise the feature flag, which segments who are going to see this new feature in a control manner in production. She opens up the feature flag window and checks the feature flag, products in alphabetical order feature flag, which has three strategies and a user list called products in alphabetical order user list, with two users in it, mickey at disney.com and mini at disney.com. The first strategy uses a percent rollout of 50% based on available ID in the production environment. The second one targets the feature to users in the users list, products in alphabetical order user list, in the staging environment. The third strategy serves the feature to a specific user, holkauniversal.com in the review environment, which is an ephemeral environment used for validating application updates before they are merged to the main branch. Feature flags help Rachel reduce risk, allowing her to do control testing and separate feature delivery from customer launch. She checks the running application in production and notices that the newly rolled out feature has a misspell header. Rachel would like to identify who introduced this feature flag and opens the project's audit events dashboard. She notices that Sasha, a developer in her organization, is the person she needs to communicate about the misspell header. While she's at it, Rachel also checks security and compliance related items of the project by going to the security dashboard. She sees that there are eight high vulnerabilities she will need to follow up on. These dashboards help Rachel preempt out of compliance scenarios to avoid penalties. They also streamline audits, provide an opportunity to optimize cost and lower risk of unscheduled production outages. We have gone over how GitLock can help you make your releases safe, lower risk worry-free, consistent and repeatable. Whether you're just starting your journey into DevOps or in the midst of it, GitLock can help you at every step, with capabilities built on DevOps and continuous delivery best practices. I hope you enjoyed this video and until next time.