 Hi, I'm César 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. Rachel 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 assignment 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 DevOps 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 on MRs provide Rachel the auditability and tracking of application changes done by the collaboration of DevOps engineers, system administrators and developers. Here we see some open issues and merge requests that are part of this project called PROD-MGR Spring. Rachel creates a milestone that will be associated with the second candidate release of the first version 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 methodology, she also creates two-week 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's 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, and streamline the approval gates and release process. At the appropriate time, Rachel creates the release, which automatically generates the release evidence and she associates the release with the V1.0 RC2 milestone. This streamlined 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 AutodevOps capabilities, which help her to automatically create the release pipeline and relieve her from manually spending time creating her own pipeline. As part of AutodevOps, she can automatically deploy to staging and manually deploy to production, as well as enable canary deployments. AutodevOps, which is based on best practices, helps Rachel streamline the release process. The first job in AutodevOps is the build job, which applies the appropriate build strategy to create a docker or container image of the application and stores it in the built-in container registry. The auto build job uses a docker file or cloud-native build packs to build your application into a container image. Faster and more reliable releases happen when you have build components like container images that are readily available to the release process in a uniform and consistent manner. Rachel verifies that the manifest digest of the container image which is built by the pipeline has indeed been stored in the built-in container registry. The auto build job could also leverage the built-in package registry to store and manage Maven artifacts so that Maven Central does not have to be scoured when building applications. She then heads over to the production environment to verify that the application has been successfully deployed and is running properly by logging onto it with a valid username. Rachel notices that the logout button color does not match the background color and verifies that there is an outstanding issue with the Timmar for it. As stakeholders make modifications to the application, 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 are merged to the main line. Review apps help increase core quality, reducing the risk of unexpected production outages. Once the application has been built and passed many automated tests, checks and verifications, the Autodevops pipeline automatically stands up a 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 base visits the temporarily deployed feature. If all 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 100% 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. Rollback 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. Monitoring tracking includes markers, the small rocket icon, 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. For manually configured Prometheus servers, Rachel could monitor the release by creating alerts to detect out of range metrics, which would be visible on the overall operations metrics dashboard, as well as on each specific environment window. Alerts can also automatically trigger the creation of incidents, chat-ups 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 ValueStream Analytics, where she can check a project or group statistics over time and see how her team improves in lead time, cycle time, lead time for changes, number of new issues, commits, deploys and deployment frequency. She can also check the median time spent in each stage defined in the process, such as issues, plan, code, test, review and staging. ValueStream Analytics are useful in order to quickly determine the velocity of a given project or group. It 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. Rachel can also track and monitor releases via Pipeline Analytics. Pipeline Analytics show 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. Pipeline Analytics also report on Dora 4 key metrics, which are performance metrics that measure the effectiveness of an organization's development and delivery practices. Deployment frequency measures how often your organization deploys code to production or release it to end users. And lead time for changes measures how long it takes to go from code committed to code successfully run in in production. Like ValueStream Analytics, Pipeline Analytics can help you identify bottlenecks in the development process, enabling management to uncover, triage and identify the root cause of slowdowns in the software development life cycle. 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. One way to enable this is for Rachel to set the Continuous Deployment option for the AutoDevOps deployment strategy. Rachel would like to exercise the Feature Flag, which segments the audience of who are going to see a new feature in a control manner in a specific environment. 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 Product in Alphabetical Order User List, with two users in it, Michael at CFL.arr.com and Mary at CFL.arr.com. The first strategy uses a percent rollout of 50% based on available ID for the production environment. The second one targets the Feature to users in the user's list, Products in Alphabetical Order User List, for the staging environment. The third strategy serves the feature to a specific user, Henry at Gmail.com, for their review environment, which is an ephemeral environment used for validating application updates before they emerge to the main branch. Feature Flags help Rachel reduce risk, allowing her to do control testing and separate feature delivery from customer launch. Rachel would like to verify the Feature Flag strategy in action in the staging environment. She opens the application in the staging environment and logs in as user Michael. She validates that Michael gets a product list sorted in alphabetical order by product name. She logs Michael out and this time she logs in as Mary. Rachel confirms that Mary also gets the feature in the staging environment. Remember that, per the Feature Flag strategy for staging, Michael and Mary were in the user's list that was allowed to see this feature in staging. Finally, she logs Mary out and still in staging, she logs in as Peter, who should not be served this feature. Indeed, Peter does not get a product list in alphabetical order. She checks the Feature Flag strategies again and notices that the strategy for the review environment has a bad email address. Rachel would like to identify who was the last person that modified this strategy of the 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 bad email address. 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 critical 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 GitLab can help you make your releases safe, low risk, worry free, consistent and repeatable. Whether you're just starting your journey into DevOps or in the midst of it, GitLab 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.