 GitLab Flow is a prescribed or opinionated end-to-end workflow for the development life cycle of applications when using GitLab. GitLab Duo is a powerful set of AI power capabilities within the GitLab DevSecOps platform. Combined, GitLab Flow and GitLab Duo can help organizations achieve significant improvements in end-to-end workflow efficiency that can lead to higher levels of productivity, deployment frequency, code quality, overall security, production resiliency, and availability. Based on best practices and lessons learned, GitLab Flow spans across the stages of the DevSecOps lifecycle, forming an efficient workflow with an inner feedback loop for reviewing specific updates and an outer feedback loop for improving the entire application as well as the development life cycle process itself. Let's go through a flow that leverages GitLab Flow and GitLab Duo and where different stakeholders participate to get work done. The first portion of the GitLab Flow is planning. Sasha is a software developer that has been tasked with adding new functionality to an existing application. Sasha proceeds to create an issue related to the new functionality, which will add the product count total and the price total of all products and inventory to the application. She takes advantage of GitLab Duo issue description generation to help enrich the description field, saving her time and effort. She navigates to her issue boards and moves her newly created issue to a list that indicates work has started. Boards are a software project management tool that can be used as Kanban on scram boards. These boards help teams plan, organize and visualize a workflow for a feature or product release. As stakeholders collaborate and discuss the new issue, Rachel, the release manager, is notified about this new request. She needs to slot it into the project schedule and she notices that many stakeholders have contributed to the discussion and instead of reading the long thread of newly added comments, she leverages GitLab Duo's discussion summary, which summarizes all issue comments into a concise paragraph so that she can quickly get caught up with the conversation, jump into the discussion and become productive right away. Next, Rachel creates a milestone. Teams can use milestones to organize issues and merge requests into a cohesive group. Milestones can be used to track releases. Rachel adds the newly created issue to the front end epic, as well as the upcoming iteration or sprint. Issues with the same theme can be grouped together in an epic to organize the work to be done. And iterations can be used to track sprints of work. Rachel adds the newly created issue to the front end epic, as well as the upcoming iteration or sprint. Issues with the same theme can be grouped together in an epic to organize the work to be done. And iterations can be used to track sprints of work. Rachel checks the iteration or sprint, burn down and burn up graphs. Burn down charts help track overall progress towards a project's total scope, while burn up charts track daily total count and weights of issues added to and completed in a given time box. She also checks the burn up and burn down charts for the milestone to visualize the progress of the work. Epics, milestones and iterations can be visualized via the roadmap's page, which helps track release progress and streamline the release process. The second portion of the GitLab flow is merge requests and pushing code. After much discussion, Sasha, the software developer, begins the implementation of the new feature. Before starting her work, however, Sasha checks the current application and notes that there are no totals for product count or pricing. From the issue, Sasha clicks on create merge request. Merge requests are where solutions are developed through collaboration among stakeholders across the organization. The creation of the merge request marks the start of the GitLab flow in her feedback loop, which is where code and fixed pushes, test and scan runs and collaboration and update reviews take place. The new feature will require updates to several source files. Sasha navigates to a file she will need to update. Unfortunately, the previous developer that worked on this file did not leave many comments in it. To help her better understand the logic of this class, Sasha selects a few lines in it and invokes GitLab Duo code explanation. This capability explains code in natural language so that she can understand the code and get up to speed quickly. This segment of code generates the displayable list of products for which she will need to compute the totals. Sasha now heads to another file where she will need to compute the totals. She opens the file in the web IDE and scrolls down the Java class source file and invokes GitLab Duo code suggestions by entering a prompt to add a new class method to calculate the count of all inventory products. She accepts the suggested code by pressing the tab key. Below the newly added method, she enters another prompt to add a new class method to calculate the prices total of all inventory products. Code suggestions recommends code that should come next and the developer can choose to accept or ignore the recommendation. Sasha then moves on to the Java class that handles the model view controller pattern to add two new attributes. The first one is for the count of all inventory products and the second one for the prices total of all inventory products. Code suggestions can help improve the programming experience by reducing errors and helping developers write code faster, which can help enhance code quality. Code suggestions also can lead to higher developer productivity and faster iterations on rollouts. Finally, Sasha opens the file that handles the main landing page of the application. She adds a small table with a row to display the headers and values for the product count and the product prices total. She commits the updates to the branch associated with the merge request and closes the web IDE and the merge request branch browser tabs. Next, she heads to the merge request overview window and consults the generated summary of all her updates by invoking the GitLab Duo merge request summary, which generates a natural language comment that summarizes her updates to the code. This can help reviewers better understand the merge request changes and streamline the entire review process. Sasha checks the pipeline that builds and deploys the application with the latest updates to an ephemeral review environment. She then checks that the application to be reviewed is up and running. If the pipeline had failed, Sasha could have taken advantage of the GitLab Duo root cause analysis, which would help her resolve errors in the pipeline execution, speeding up the development process. Back in the merge request, Sasha is ready for all her changes to be reviewed by other stakeholders. By clicking on select reviewers, she leverages GitLab Duo suggested reviewers, which lists the users that are knowledgeable about a specific aspect of this application and would be the best candidates to review the updates. Sasha saves time by not having to search and identify adequate reviewers, streamlining the review process and avoiding delays and low quality reviews. Sydney, a system and database administrator, is one of the reviewers of Sasha's merge request. Sydney enters one last review comment and finishes her review by invoking GitLab Duo code review summary, which appends a comment to the merge request, summarizing her review. This will help Sasha better understand what Sydney's review was all about and enables better handoff between authors and reviewers, streamlining the review process. Once all reviewers have performed their reviews, Sasha reads each of the generated summaries from each stakeholder suggestions and comments to get more context and better understand the proposed changes. She then proceeds to go over each suggestion and comment and resolves all review threads. Sasha notices the lack of some unit tests for some of the functionality in the application. She heads to the Java class for which tests could be created and opens it in the Web IDE. She selects the lines for which she'd like to have tests and invokes GitLab Duo test generation. Test generation understands the context and generates sample tests in the appropriate programming language, relieving developers from the repetitive task of creating coverage tests. Sasha copies the generated tests, creates a new file in the project directory structure and paste the code for the test into it. At this moment, she could commit the updates with the new test to the branch. But instead, she opts to postpone this for the next iteration so she closes the Web IDE, discarding the changes. Security and compliance are paramount in the organization and shifts in security left is a mandate for all projects to detect and resolve defects as early as possible in the software development process. It is much cheaper and simpler to fix vulnerabilities early in the development lifecycle than once the application is in production where unscheduled outages can affect end users and revenue. To this end, Amy, a security engineer, has created a compliance pipeline and set it up so that it will always be enforced with every project pipeline run. In addition, Amy has set up security scan policies to be executed automatically within a merge request pipeline. Scan execution policies require that security scans be run on a specified schedule or with the project pipeline and scan result policies take action based on scan results. Security engineers or teams can define these policies to enforce security processes across the organization and GitLab Flow may encounter or leverage these as it spans through its steps. With this approach, Amy can ensure that all teams within her organization meet security and compliance standards. In addition, she can secure applications against cyber attacks, conform to government compliance standards and always be audit ready. Company-wide security and compliance enforcement mechanisms can also be enacted in each project. As updates are applied to the feature branch by stakeholders, merge request pipelines that shift security left run. Sasha heads to the merge request pipeline and goes over the results of the many security scanners in its test stage. GitLab provides a variety of fully integrated unsupported scanners all in a single platform. Besides scanners, GitLab provides a variety of security dashboards and reports to manage and visualize vulnerabilities such as the security dashboard, dependency list, license and compliance and vulnerability report. Sasha locates a SAS vulnerability and invokes GitLab Duo vulnerability summary which provides an explanation about the vulnerability, how it can be exploited and most importantly, a recommendation on how to fix it. Vulnerability summary can help optimize the process of securing and hardening an application to prevent vulnerabilities that can be exploited by cyber attacks in production. The next portion of the GitLab flow is the continuous review of applications. In this portion, a review environment is stood up and the application is continuously deployed to it as branch updates are pushed via its associated merge request pipeline. The interim application can then be continuously reviewed and adjusted by stakeholders until it is ready to be merged to the main branch. Sasha verifies that the interim application works as expected. When the merge request is merged to the main branch, all provision review environment resources are automatically cleaned up. A pipeline is kicked off against the updated main branch and all security and compliance checks are carried out again, but this time the deployment will be to the staging and production environments. The next portion of GitLab flow is related to deploying applications. Sasha has been using AutodevOps for her project. AutodevOps is a collection of predefined out-of-the-box CI CD templates that Autodescover the source code she has. Based on best practices, these templates automatically detect, build, test, deploy, and monitor her applications. Think of AutodevOps as a good example for the instantiation of GitLab flow. Sasha is currently using the continuous delivery option for AutodevOps that shifts security left and then deploys the application to the staging environment followed by an incremental deployment to production. Another option is continuous deployment where all application updates are deployed directly to production. Incremental rollouts can lower the risk of production outages delivering a better user experience and customer satisfaction. The incremental deployment is reflected in the executed pipeline. Advanced deployment techniques like Canary, Blue-Green, Untimed and incremental rollouts can also improve development and delivery efficiency streamlined in the release process. As application updates are deployed to the review staging and production environments, a good way to reduce risk and manage what functionality to make available to users is feature flags. They allow Sasha to granularly define who her audience will be for a specific feature. Feature flags can also separate feature delivery from a customer launch. A user list has been defined. Two users, Michael and Mary, are in this user list. A feature flag called products in alphabetical order which lists the products in the inventory in alphabetical order in the user interface has been defined. Notice that a toggle can enable or disable this feature flag in the running application. Strategies have been defined for production, staging and review environments. Sasha reviews the strategy for production which specifies that half of the users will get the feature and half will not. For staging, the predefined user list is being used for the users that will get the feature. And for the review environment, only user Thomas will get the feature. In addition, Sasha ensures that the strategy for review is being applied to the correct review environment since there are many concurrent merge requests developers are working on. To check the application for integrity, Sasha verifies that the strategy for the staging environment is indeed being applied. She opens the running application in staging and first logs on as Michael who gets the products order in alphabetical order. Sasha reopens the application in staging and logs in as Mary who also gets the feature. Remember that Mary and Michael were in the predefined user list used by this strategy. To verify that nobody other than Mary and Michael get the feature, she logs on as Thomas and sees that he does not get the list of products listed in alphabetical order as defined by the strategy for staging. Sasha can use feature flags to roll out features to specific users, reducing risk of unexpected outages or rollbacks. Now that the application is up and running in different environments, how can stakeholders monitor the application as well as the DevSecOps processes? Sydney, the system administrator can easily track application statuses via the operations dashboard, which provides a summary of each project's operational health, including pipeline and alert status. 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. Sydney can also monitor the resources of the Kubernetes cluster hosting the environments where the application is running. These dashboards provide Sydney with the operations insights she needs to understand how the release is performing in production and quickly identify and troubleshoot any production issues. Another way to monitor the running application and its underlying infrastructure is through the GitLab agent for Kubernetes. Sydney, the system administrator, checks the connectivity of GitLab with the Kubernetes cluster. As containers are deployed to the cluster, operational container scanning is performed and its results are displayed in this window. Amy can see that a container was deployed with a vulnerability so she can quickly fix or advise the appropriate team to fix it, preventing cyber attacks and unexpected outages and damage to the organization's reputation. Error tracking is another way to closely monitor running applications. In the error tracking list, Sydney, the system administrator, can discover and view any errors emitted by the application and get to troubleshooting and fixing them right away. Error tracking can help with availability and performance of applications by detecting and resolving unexpected application conditions fast. Alerts from systems monitoring and alerting tools like Prometheus can also help visualize and troubleshoot and handle out of range situations before they bring down running applications. Sydney can view and manage alerts from the alerts list. Alerts can also automatically trigger the creation of incidents, chat ops and email messages to appropriate individuals or groups. All these capabilities streamline the alert resolution and management process. As incidents are created due to production problems, they appear in the GitLab incidents list for incident management. Sydney can manage one or more incidents, search them, sort them, set their statuses, track their SLA preset countdown timer, assign them and even see if the incident has been published to a GitLab status page for centralized monitoring. Moreover, she can create on-call schedules and rotations, escalation policies, and set up page and notifications to handle incidents. In addition, she can link an incident to an alert so that when the incident is closed, its associated alert is automatically resolved. All these capabilities streamline the incident management process so that they can be resolved as quickly as possible. Security engineers like Amy may need to know what changes took place in the GitLab platform when troubleshooting security issues. Amy notices that there is an invalid email in a strategy for a feature flag. Amy checks the audit events to track important events, including who performed a related action and when in GitLab. Here, Amy sees that an erroneous email was entered in a feature flag strategy by Sasha. In addition, Amy has the compliance center in which she can visualize standards, adherence, violations, and compliance frameworks for a group. All these lists and dashboards can help preempt out of compliance scenarios to avoid penalties as well as streamline audit processes. For running applications, they generate the data and metrics that can be used in the GitLab flow, audit feedback loop to help improve and optimize applications, and lower the risk of unscheduled production outages. Besides continuously improving applications, GitLab Flow provides insight to help continuously improve your software delivery processes. This brings us to the last portion of the GitLab Flow, which is for continuous improvement. GitLab provides end-to-end process-related dashboards and metrics which are auto-generated and always available. Dakota, the application development director, checks the Value Stream Analytics dashboard to see how well her organization has been carrying out the DevSecOps lifecycle stages. She does this at the group level. Value Stream Analytics are useful to quickly determine the velocity of a given project or group. They point to bottlenecks in the development process, enabling management to uncover, triage, and identify the root cause of the slowdowns in the software development lifecycle, allowing for the introduction of improvements that generate value to the organization. Pipeline Analytics show the history of pipeline successes and failures, as well as how long each pipeline ran, helping her understand the health of projects and their continuous delivery. She does this for a specific project in her organization. Pipeline Analytics also report on Dora Key Metrics, which are performance metrics that measure the effectiveness of an organization's development and delivery practices. Change Failure Rate is the number of incidents divided by the number of deployments to a production environment in a selected time range. Time to restore service is the median time an incident was opened in a production environment in a selected time range. Lead Time for Changes measures how long it takes to go from code committed to code successfully running in production. Deployment Frequency measures how often your organization deploys code to production or releases it to end users. Dakota wants to get a glimpse into how deployment frequency will trend into the future. She leverages GitLab Dual Value Stream Forecasting, which takes historical data and uses data trends across the development lifecycle to predict the future behavior. She can use these predictive analyses in her optimization initiatives. Like Value Stream Analytics, Pipeline Analytics and Dora Metrics help identify bottlenecks in the development process, enabling management to uncover, triage, and identify the root cause of the slowdowns in the software development lifecycle, allowing for the introduction of improvements that generate value to the organization. All these dashboards and the metrics they report on are part of the GitLab Flow Outer Feedback Loop to help lower the risk of unscheduled production outages and improve and optimize your applications and DevSecOps workflows. Why use GitLab Flow with GitLab Duo? Combine, they can help you achieve higher productivity, continuous improvement, higher code quality, better application security, compliance and audit readiness, continuous review, application optimization via the GitLab Flow Inner Feedback Loop, development lifecycle optimization via the GitLab Flow Outer Feedback Loop, high collaboration, lower risk for deployments, boosted efficiency and productivity via GitLab Duo capabilities, and support for cloud native and non-cloud native applications. Combine GitLab Flow and GitLab Duo for a workflow powerhouse.