Scaled Agile SAFe-DevOps Exam Actual Questions

The correct order of activities in the Continuous Integration aspect is: Develop, Build, Test end-to-end, Stage. Continuous Integration (CI) is an aspect of the Continuous Delivery Pipeline that automates the development, testing, integration, and validation of new functionality in preparation for deployment and release. CI is the second aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. CI consists of four activities, as shown in Figure 1:

Develop -- This activity involves implementing stories by refining features from the ART Backlog, coding, testing, and committing the work product into the source control system. Testing in this activity tends to focus on unit and story-level testing and often requires test doubles to replicate other components or subsystems that are not readily available or easily tested.

Build -- This activity involves creating deployable binaries and merging development branches into the trunk. Building in this activity includes compiling, linking, packaging, and verifying the code and components. Building also involves applying code quality and security checks, such as static code analysis, code coverage, and code review.

Test end-to-end -- This activity involves validating the solution end-to-end, including the functional and nonfunctional aspects, such as performance, usability, reliability, and security. Testing in this activity requires integrating the code and components with other subsystems and services, and using test environments that resemble the production environment as much as possible. Testing also involves applying automated testing tools and frameworks, such as regression testing, integration testing, system testing, and acceptance testing.

Stage -- This activity involves hosting and validating solutions in a staging environment before production. Staging in this activity includes deploying the solution to a pre-production environment that mimics the production environment in terms of hardware, software, configuration, and data.Staging also involves applying final checks and verifications, such as smoke testing, exploratory testing, and user acceptance testing910

1: https://www.lean.org/the-lean-post/articles/understanding-the-fundamentals-of-value-stream-mapping/2: https://www.gembaacademy.com/school-of-lean/value-stream-mapping/adapting-value-stream-mapping-for-office-and-service-environments/what-is-the-c-a-percentage-complete-accurate-metric3: https://scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/4: https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps5: https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment6: https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html7: https://scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/8: https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps9: https://scaledagileframework.com/continuous-integration/10: https://support.scaledagile.com/s/article/Exam-Study-Guide-SDP-6-0-SAFe-for-DevOps

Gated commits are a key technical practice that enables trunk-based development. Gated commits are a mechanism that ensures that only code that passes certain quality checks and tests can be committed to the main trunk of the shared codebase. Gated commits prevent broken changes from affecting other developers or the Continuous Delivery Pipeline. Gated commits typically involve the following steps:

A developer writes code and runs local tests on their own machine or branch.

The developer pushes the code to a remote repository, where a pre-commit hook triggers a build and test process on a separate server.

The build and test process verifies that the code meets the quality standards and does not introduce any errors or conflicts with the existing code on the trunk.

If the build and test process succeeds, the code is automatically merged into the trunk and becomes available for other developers and downstream activities.

If the build and test process fails, the code is rejected and the developer is notified of the issues that need to be fixed before retrying the commit.

Gated commits support trunk-based development by ensuring that the trunk is always in a releasable state, which means that at least once a day, developers must integrate their changes to the trunk. This is accomplished through short-lived feature branches related to project tasks.Gated commits reduce the complexity and conflicts of merging long-lived branches, improve the quality and consistency of the code by enforcing frequent testing and validation, accelerate the delivery and deployment of new functionality by minimizing the transaction cost and risk, and foster a culture of collaboration and transparency among developers

Lean flow is the DevOps principle that focuses on identifying and eliminating bottlenecks in the Continuous Delivery Pipeline. Lean flow is the application of Lean thinking and principles to optimize the flow of value from ideation to delivery. Lean flow aims to reduce waste, increase efficiency, and deliver value faster and more reliably. Lean flow involves the following practices:

Reducing batch size -- Breaking down large batches of work into smaller, more manageable pieces that can be delivered more frequently and with less risk.

Limiting work in progress (WIP) -- Restricting the amount of work that can be started or in flight at any given time, to avoid overloading the system and creating queues and delays.

Implementing pull systems -- Aligning the production and consumption of work by allowing downstream customers to pull work from upstream suppliers when they are ready, rather than pushing work based on forecasts or schedules.

Managing queue lengths -- Monitoring and controlling the amount of work waiting to be processed at each stage of the value stream, to reduce lead time and variability.

Reducing handoffs -- Minimizing the number of transitions and dependencies between different teams or individuals, to avoid communication gaps, context switching, and rework.

Implementing Work in Process (WIP) visualization -- Making the work and its status visible to all stakeholders, using tools such as Kanban boards, Cumulative Flow Diagrams (CFDs), and Value Stream Maps (VSMs), to enable collaboration, coordination, and improvement.

Implementing Work in Process (WIP) feedback -- Establishing fast and frequent feedback loops within and across the value stream, using tools such as automated testing, monitoring, and metrics, to detect and resolve issues, validate assumptions, and learn from outcomes3

Canary releases are used to allow incremental release of new functionality to customers. A canary release is a change management strategy for software releases that reduces the downtime and risk of deploying new versions of software. A canary release involves having two identical but separate environments: one is the active environment that serves the user traffic, and the other is the inactive environment that hosts the new version of the software. The release process consists of switching a small portion of the user traffic from the active environment to the inactive environment, after verifying that the new version is working properly. The portion of users who receive the new version are called canaries, as they serve as early indicators of the quality and performance of the new version. The canary release has several benefits, such as:

It allows for fast and reliable rollback, in case of any issues or errors in the new version, by simply switching back to the active environment.

It eliminates the need for complex and error-prone migration scripts, as the inactive environment can be prepared and tested in advance, without affecting the active environment.

It enables testing and experimentation of the new version with a subset of users, by directing some user traffic to the inactive environment, before switching completely.

It facilitates continuous delivery and deployment, by automating the switching process and reducing the transaction cost and risk of moving changes to production

Two areas that should be monitored in the Release on Demand aspect to support DevOps and Continuous Delivery are the build status and the deployment cycle time. The build status is the measure of whether the code and components can be successfully compiled, linked, packaged, and verified into deployable binaries. The build status indicates the quality and consistency of the code and the readiness for deployment. Monitoring the build status helps to support the Release on Demand aspect in SAFe by providing valuable information for the following purposes:

To identify and fix any errors or defects that may prevent the code from being deployed or released

To ensure that the code meets the quality standards and security checks, such as static code analysis, code coverage, and code review

To verify that the code and components are integrated and merged correctly into the trunk

To track the progress and status of the features and capabilities that are being developed and delivered

The deployment cycle time is the measure of how long it takes to deploy the code and components from the source control system to the production environment. The deployment cycle time indicates the efficiency and reliability of the deployment process and the speed of delivery. Monitoring the deployment cycle time helps to support the Release on Demand aspect in SAFe by providing valuable information for the following purposes:

To optimize the deployment process and reduce the lead time and variability

To automate the deployment process and eliminate manual steps and errors

To align the deployment process with the market demand and release strategy

To evaluate the impact and value of the deployed features and capabilities7