Module 1 - DevOps

2-Mark Questions (Short & Direct Answers)

1. Outline core values that lead to the DevOps philosophy. The core values of DevOps are often
summarized by the acronym CAMS:
• Culture: Fostering collaboration, shared responsibility, and breaking down silos between Dev
and Ops teams.
• Automation: Automating repetitive tasks in the software delivery lifecycle to increase speed and
reduce errors.
• Measurement: Collecting data and metrics from the pipeline and production to drive continuous
improvement.
• Sharing: Encouraging transparency and the sharing of knowledge, tools, and feedback across
teams.

2. State primary goals achieved through DevOps implementation. The primary goals of
implementing DevOps are:
• Increased Deployment Frequency: Releasing software to production faster and more often.
• Improved Reliability and Stability: Reducing the failure rate of new releases and decreasing
the time to recover from failures.
• Lower Lead Time: Shortening the time it takes from a code commit to that code running in
production.

3. Classify deployment models aligned with DevOps in cloud environments.

• Blue-Green Deployment: Two identical production environments ("Blue" and "Green") are
maintained. The new release is deployed to the inactive environment, and once tested, traffic is
switched over instantly.
• Canary Deployment: The new version is released to a small subset of users first. If it performs
well, it's gradually rolled out to the entire user base.
• Rolling Deployment: The new version is slowly deployed by replacing old instances with new
ones one by one or in batches, ensuring no downtime.

4. List the stages in a standard DevOps pipeline.

1. Plan: Define features and track work.
2. Code: Develop code and manage it in version control.
 3. Build: Compile the code into a runnable artifact.
4. Test: Run automated tests to validate quality.
5. Deploy: Release the artifact to an environment.
6. Operate: Manage and maintain the application in production.
7. Monitor: Collect feedback and performance data.

5. Identify tools commonly used in continuous monitoring.

• Prometheus: For collecting time-series metrics.
• Grafana: For visualizing metrics and creating dashboards.
• ELK Stack (Elasticsearch, Logstash, Kibana): For log aggregation, processing, and
visualization.
• Datadog / New Relic: For Application Performance Monitoring (APM).

6. Choose an appropriate automation tool for the build phase and justify its fit.
• Tool: Maven (for Java projects).
• Justification: Maven is a suitable fit because it standardizes the entire build process. It manages
project dependencies, compiles the source code, runs unit tests, and packages the code into a
runnable format (like a JAR or WAR file), all through a simple, declarative XML file
([Link]). This makes builds repeatable and easy to automate in a CI server like Jenkins.

7. Match a DevOps practice with a corresponding Agile value.

• DevOps Practice: Continuous Integration/Continuous Deployment (CI/CD).
• Agile Value: "Working software over comprehensive documentation." CI/CD embodies this
value by focusing the team's effort on automating the delivery of functional, tested software to
users as quickly as possible, rather than on creating extensive deployment manuals.

5-Mark Questions (Descriptive Answers)

1. Demonstrate the integration flow from code commit to deployment using DevOps stages. The
flow from a code commit to a live deployment is a highly automated process in a mature DevOps
environment, orchestrated by a CI/CD pipeline.
1. Code & Commit: A developer writes code for a new feature on a dedicated branch in a Git
repository (e.g., GitHub). Once the feature is ready, they push the commit.
 2. Trigger & Build: The git push event automatically triggers a webhook that notifies a CI
server like Jenkins. Jenkins checks out the code and starts a build job. It uses a tool like Maven
or Gradle to compile the source code and package it into an artifact (e.g., a Docker image).
3. Test: During the build process, automated tests are executed. This includes fast unit tests (using
JUnit) to check individual components and static code analysis (using SonarQube) to check for
code quality and security vulnerabilities. If any of these tests fail, the pipeline stops and notifies
the developer.
4. Deploy to Staging: If the build and initial tests are successful, the CI/CD pipeline automatically
deploys the artifact to a staging or testing environment. This environment is a replica of
production.
5. Continuous Testing: Once deployed to staging, a suite of more comprehensive tests is run. This
includes integration tests to verify that different services work together correctly and end-to-
end tests (using Selenium) that simulate user journeys.
6. Deploy to Production: If all staging tests pass, the artifact is considered ready for release.
Depending on the organization's policy, the pipeline may require a manual approval before
proceeding. The artifact is then deployed to the production environment using a safe
deployment strategy like Blue-Green or Canary to ensure zero downtime.

2. Illustrate typical transitions observed in teams shifting from Agile to DevOps. Shifting from
Agile to DevOps is a natural evolution where Agile's principles of iterative development are extended
beyond coding to include operations and the entire delivery lifecycle.
• From "Done" meaning "Code Complete" to "Done" meaning "Running in Production":
In Agile, a story is often "done" when the code is written and passes tests. In DevOps, a story is
only truly "done" when it is successfully deployed and delivering value to end-users in
production.
• From Team Silos to Cross-Functional Teams: Agile teams focus on breaking down barriers
between developers, BAs, and testers. DevOps extends this by integrating operations engineers
into the development team, creating a single team responsible for the entire product lifecycle.
• From Manual Handoffs to Full Automation: Agile teams may still rely on a manual handoff
to an operations team for deployment. The transition to DevOps requires automating this entire
release process through a CI/CD pipeline, eliminating the need for manual intervention.
• From Focusing on Features to Focusing on Value and Stability: While Agile focuses on
delivering features in sprints, DevOps adds a focus on the operational stability and performance
of those features. The team becomes responsible not just for building the software, but also for
running and monitoring it.
• From Project-Based Metrics to Product-Based Metrics: The focus shifts from measuring
project metrics like "velocity" to measuring product metrics like deployment frequency, lead
time for changes, and mean time to recovery (MTTR).
3. Examine the shifts in developers' responsibilities with DevOps adoption. With the adoption of
DevOps, the role of a developer expands significantly, moving from being purely a "coder" to an owner
of the entire software lifecycle. This is often summarized by the phrase "You build it, you run it."
• Operational Awareness: Developers are now expected to understand the production
environment where their code will run. They need to consider aspects like scalability,
monitoring, and fault tolerance during the development phase.
• Ownership of Testing: While dedicated QA engineers still exist, developers take on more
responsibility for writing automated tests, including not just unit tests but also integration and
contract tests. They are responsible for ensuring their code is testable.
• Involvement in CI/CD: Developers are expected to understand and contribute to the CI/CD
pipeline. They may need to write or modify pipeline configuration files (e.g., Jenkinsfile,
[Link]) to build, test, and deploy their services.
• Responsibility for Monitoring and Alerting: Developers are now often part of the on-call
rotation. They use monitoring tools (like Grafana and Prometheus) to observe how their code
behaves in production and are responsible for responding to alerts related to their services.
• Security as a Responsibility ("DevSecOps"): Security is no longer an afterthought.
Developers are responsible for writing secure code and using tools for static and dynamic
security scanning early in the development process ("shifting left").

4. Apply DevOps principles to reduce lead time in a release cycle scenario. Scenario: A company
takes 4 weeks (the "lead time") to get a new feature from a developer's machine to production. The
process involves 1 week of coding, 1 week of manual testing by QA, 1 week for integration, and 1
week for a manual deployment by the Ops team.
Applying DevOps Principles to Reduce Lead Time:
1. Implement Continuous Integration (CI): Instead of a 1-week integration phase, developers
merge their code into a shared repository multiple times a day. A CI server like Jenkins
automatically builds and runs unit tests on every single commit.
• Impact: This eliminates the painful, week-long integration phase and catches integration
issues within minutes, not weeks. Lead time reduced by 1 week.
2. Automate Testing (Continuous Testing): The 1-week manual testing phase is replaced with a
suite of automated tests. This includes unit, integration, and end-to-end tests that run
automatically as part of the CI/CD pipeline.
• Impact: Testing time is reduced from a week to a matter of hours or even minutes. This
provides faster feedback and frees up QA engineers to focus on more valuable
exploratory testing. Lead time reduced by another week.
 3. Automate Deployment (Continuous Deployment): The 1-week manual deployment process is
replaced with an automated deployment script in the pipeline. Once all tests pass, the code can
be deployed to production with a single click (or even automatically).
• Impact: Deployments become a routine, low-risk activity that takes minutes, not a week
of planning and manual work. Lead time reduced by another week.
4. Embrace Small Batch Sizes: Instead of bundling many features into one large quarterly
release, the team releases each small feature as soon as it's ready.
• Impact: Small changes are less risky, easier to test, and easier to troubleshoot if
something goes wrong. This further reduces the time and effort required for each release.
By applying these principles, the lead time is reduced from 4 weeks to potentially just a few hours.

5. Construct a deployment workflow incorporating continuous testing and integration. This

workflow shows how Continuous Integration (CI) and Continuous Testing (CT) are deeply embedded
to ensure code quality before deployment.
1. Developer Commits Code: A developer commits code to a feature branch in a Git repository.
2. Continuous Integration (CI) Trigger:
• A CI server (Jenkins) is triggered by the commit.
• Step 1: Build & Unit Test: Jenkins builds the code and runs fast unit tests. If this fails,
the developer is notified immediately.
• Step 2: Static Analysis: Tools like SonarQube scan the code for quality issues and
security vulnerabilities. The pipeline fails if the quality gate is not met.
• Step 3: Create Pull Request: The developer creates a Pull Request (PR) to merge the
feature into the main develop branch.
3. Continuous Testing (CT) on Pull Request:
• The PR triggers a more extensive set of tests.
• Step 4: Deploy to a Test Environment: The code is automatically deployed to a
temporary, isolated testing environment.
• Step 5: Run Integration & API Tests: Automated tests run against this environment to
ensure the new feature works correctly with other parts of the application and external
services.
• Step 6: Code Review: The PR is reviewed by another team member.
4. Merge and Deploy:
• Step 7: Merge to Develop: If all tests pass and the PR is approved, the code is merged
into the develop branch.
 • Step 8: Deploy to Staging: The merge triggers another pipeline run that deploys the
application to a permanent staging environment for final validation.
• Step 9: Run E2E & Performance Tests: A final suite of end-to-end tests and
performance tests are run in staging.
5. Release to Production:
• If all steps are successful, the build artifact is promoted and deployed to production.

6. Justify the role of cloud-native practices within DevOps environments. Cloud-native practices
are not just compatible with DevOps; they are essential enablers that provide the technical foundation
needed to achieve DevOps goals of speed, scalability, and reliability.
• Containers (e.g., Docker): Containers provide immutable infrastructure. They package an
application with all its dependencies, ensuring that it runs consistently across all environments
(dev, test, prod). This eliminates the "it works on my machine" problem, a key goal of DevOps.
• Container Orchestration (e.g., Kubernetes): DevOps aims for resilient and scalable systems.
Kubernetes automates the deployment, scaling, and management of containerized applications.
It can automatically handle failures by restarting containers, and it can scale applications up or
down based on demand, which is crucial for maintaining a reliable service.
• Microservices Architecture: DevOps emphasizes small, independent teams owning their
services. A microservices architecture, where an application is broken down into small,
independently deployable services, aligns perfectly with this. It allows teams to develop, test,
and deploy their services without being blocked by other teams, dramatically increasing
deployment frequency.
• Infrastructure as Code (IaC) (e.g., Terraform): A core DevOps principle is automation. IaC
allows teams to manage and provision their cloud infrastructure through code. This makes
infrastructure setup repeatable, version-controlled, and automated, which is essential for
creating consistent environments on demand.
In essence, DevOps provides the culture and process, while cloud-native practices provide the tools
and architecture to make that process a reality at scale.

7. Analyze the coordination between DevOps engineers and QA in a microservices project. In a

microservices project, the traditional siloed relationship between developers, QA, and operations is
completely redefined. DevOps engineers and QA must coordinate closely to build quality into the
automated delivery process.
• Shared Goal: Building a Reliable Pipeline: The primary point of coordination is the CI/CD
pipeline. The DevOps engineer is responsible for building and maintaining the infrastructure of
the pipeline (e.g., setting up Jenkins, Kubernetes), while the QA engineer is responsible for
integrating the automated testing tools and frameworks into that pipeline.
• QA's Role Shifts to "Quality Assistance": Instead of being a gatekeeper who manually tests
at the end of a cycle, the QA engineer acts as a coach for the development team. They help
developers write better, more effective automated tests for their microservices.
• DevOps Engineer's Role is to Enable Testing: The DevOps engineer provides the necessary
environments and infrastructure for testing. This includes spinning up ephemeral (temporary)
environments for each Pull Request so that integration tests can be run in isolation without
conflicts.
• Joint Ownership of Test Data Management: In a microservices architecture, managing test
data is complex. The QA and DevOps engineers must work together to create automated
solutions for provisioning and cleaning up test data in the various testing environments.
• Focus on Contract and API Testing: For microservices, the most critical tests are at the API
level (contract testing). QA defines the testing strategy, and the DevOps engineer ensures the
pipeline has the tools (like Postman/Newman) and capability to run these tests automatically
and efficiently.
• Collaboration on Monitoring: Both roles are concerned with quality in production. QA helps
define what application metrics are important to monitor (e.g., error rates, latency), and the
DevOps engineer implements the monitoring and alerting tools (like Prometheus and Grafana)
to track them.