R21 Regulations

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY ANANTAPUR

(Established by Govt. of A.P., ACT No.30 of 2008)
ANANTHAPURAMU – 515 002 (A.P) INDIA

MASTER OF COMPUTER APPLICATIONS

Course Code DEV OPS & AGILE PROGRAMMING LABORATORY L T P C

21F00308 0 0 4 2
Semester III

Course Objectives:
To understand the concept of DevOps with associated technologies and
• methodologies.
• To be familiarized with Jenkins, which is used to build & test software Applications
• & Continuous integration in Devops environment. To understand different Version
• Control tools like GIT, CVS or Mercurial
• To understand Docker to build, ship and run containerized images
• To use Docker to deploy and manage Software applications running on Container.
• To be familiarized with concept of Software Configuration Management &
• provisioning using toolslikePuppet,Chef, Ansible or Saltstack.
Course Outcomes (CO):
• Understand and Implement the Integration and Continuous deployment.
• Can implement anatomy of continuous delivery pipeline.
• Understands and implement static code analysis.
List of Experiments:
Agile Laboratory Programs:

1. Understand the background and driving forces fortaking an Agile Approach to Software
Development.
2. Understand the business value of adopting agileapproach.
3. Understand agile development practices
4. Drive Development with Unit Test using Test Driven development.
5. Apply Design principle and Refactoring to achieve agility
6. To study automated build tool.
7. To study version control tool.
8. To study Continuous Integration tool.
9. Perform Testing activities within an agile project.

Dev Ops Laboratory Programs:

1. Build & TestApplicationswithContinuousIntegration - To Install and Configure Jenkins to

test, anddeploy Java or Web Applications usingNetBeans or eclipse.
2. VersionControl - To Perform Version Control on websites/Software’s using different
Version control toolslike RCS/ CVS/GIT/Mercurial (Any two)
3. Virtualization&Containerization - To Install and Configure Docker for creatingContainers
of different Operating SystemImages
4. Virtualization&Containerization - To Build, deploy and manage web orJava application on
Docker
5. SoftwareConfigurationManagement - To install and configure
Software ConfigurationManagement using Chef/Puppet/Ansible orSaltstack.
6. Provisioning - To Perform Software ConfigurationManagement
and provisioning usingChef/Puppet/Ansible or Saltstack.
Experiment 1: Introduction to Agile Development
Objective:

To understand the background and driving forces behind adopting an Agile approach to
software development. This experiment aims to introduce students to the core principles,
values, and historical context of Agile methodologies, helping them appreciate why Agile is a
preferred approach in modern software development.

Theory:

Agile development is an iterative and incremental approach to software development that

emphasizes flexibility, collaboration, and customer satisfaction. The Agile Manifesto, created
in 2001 by a group of software developers, lays out four core values and twelve principles
that guide Agile practices.

Core Values of the Agile Manifesto:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Key Agile Principles:

 Deliver working software frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale.
 Business people and developers must work together daily throughout the project.
 The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
 Continuous attention to technical excellence and good design enhances agility.

Materials Required:

 Access to articles and resources on Agile methodology.

 Agile Manifesto (available online).
 Case studies of Agile implementations in the industry.

Procedure:

1. Introduction to Agile:
o Begin with a lecture or presentation on the history of software development
methodologies, leading up to the creation of Agile.
o Discuss the limitations of traditional development methods like Waterfall and
how Agile addresses these limitations.
2. Study of the Agile Manifesto:
o Read through the Agile Manifesto, understanding the core values and
principles.
o Participate in a group discussion on how these values and principles contrast
with traditional software development practices.
 3. Case Study Analysis:
o Analyze a case study where Agile methodology was implemented in a real-
world project.
o Identify the key challenges faced in the project and how Agile practices helped
overcome them.
4. Group Activity:
o Divide students into small groups and assign each group a traditional
development scenario.
o Each group will then discuss how they could approach the same scenario using
Agile practices.
o Present the findings to the class, focusing on how Agile would change the
development process.
5. Discussion and Q&A:
o Engage in a class-wide discussion on the benefits and challenges of adopting
Agile.
o Encourage students to ask questions and share their insights.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand the historical context and driving forces behind the Agile movement.
 Explain the core values and principles of the Agile Manifesto.
 Recognize the differences between Agile and traditional software development
approaches.
 Discuss real-world examples of Agile implementation and its impact on software
projects.
Experiment 2: Understanding the Business Value of Agile
Objective:

To understand the business value of adopting Agile practices in software development. This
experiment focuses on identifying the benefits that Agile methodologies bring to businesses,
including improved time-to-market, enhanced customer satisfaction, and increased
adaptability to change.

Theory:

Agile methodologies are designed to deliver value to the business by fostering a development
process that is responsive to changing requirements and customer needs. By emphasizing
iterative development, close collaboration with stakeholders, and a focus on working
software, Agile helps businesses achieve their goals more effectively and efficiently.

Key Business Benefits of Agile:

 Faster Time-to-Market: Agile's iterative approach allows for frequent releases,

enabling businesses to get products to market quicker.
 Enhanced Customer Satisfaction: Continuous involvement of customers in the
development process ensures that the final product meets their needs.
 Increased Flexibility: Agile’s responsiveness to change allows businesses to pivot
based on market conditions or customer feedback.
 Improved Quality: Agile practices like continuous integration and test-driven
development (TDD) lead to higher-quality software.
 Risk Reduction: By delivering in smaller increments, Agile reduces the risk
associated with long development cycles.

Materials Required:

 Access to Agile case studies that highlight business impacts.

 Tools for creating presentations (e.g., PowerPoint, Google Slides).
 Articles or white papers on the business benefits of Agile (available online).

Procedure:

1. Introduction to Business Value in Agile:

o Begin with a brief lecture or presentation on why businesses are increasingly
adopting Agile methodologies.
o Discuss how traditional project management approaches often lead to delays,
increased costs, and misalignment with business goals.
2. Case Study Analysis:
o Choose a case study where a company adopted Agile practices and
experienced significant business benefits.
o Analyze the case study, focusing on the challenges the company faced before
adopting Agile and the outcomes after implementation.
o Identify specific metrics such as time-to-market, customer satisfaction scores,
and return on investment (ROI) that improved after adopting Agile.
3. Group Activity:
 o Divide the class into small groups and assign each group a different aspect of
business value (e.g., time-to-market, customer satisfaction, flexibility, quality,
risk reduction).
o Each group will research and create a presentation on how Agile practices
specifically impact their assigned area of business value.
o Groups will present their findings to the class, highlighting real-world
examples and data where possible.
4. Discussion and Reflection:
o After the presentations, engage the class in a discussion on how these business
benefits could apply to various industries and types of projects.
o Reflect on how Agile's focus on delivering business value can influence
decision-making in software projects.
5. Individual Report:
o Each student will write a report summarizing the key business benefits of
Agile, using insights from the case studies and group presentations.
o The report should also include a section on how Agile could be beneficial in a
project they have worked on or might work on in the future.

Expected Outcome:

By the end of this experiment, students should be able to:

 Articulate the key business benefits of Agile methodologies.

 Understand how Agile practices can lead to faster time-to-market, improved customer
satisfaction, and increased flexibility.
 Analyze and present real-world case studies that demonstrate the business value of
Agile.
 Reflect on how Agile principles could be applied to enhance business outcomes in
various projects.
Experiment 3: Understanding Agile Development Practices
Objective:

To understand and apply core Agile development practices such as Scrum, Kanban, and
Extreme Programming (XP). This experiment aims to provide hands-on experience with
these methodologies, allowing students to learn how Agile teams operate and manage work
effectively.

Theory:

Agile development practices are a set of methods that help teams collaborate effectively,
manage tasks, and deliver high-quality software. These practices include frameworks like
Scrum, which organizes work into sprints and ceremonies; Kanban, which visualizes work
and limits work in progress; and XP, which emphasizes technical excellence and frequent
releases.

Key Agile Development Practices:

 Scrum: A framework for managing work in iterations called sprints. It includes roles
(Product Owner, Scrum Master, Development Team), events (Sprint Planning, Daily
Standup, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint
Backlog, Increment).
 Kanban: A visual management tool that uses a board to track tasks across various
stages of completion. It focuses on continuous delivery, limiting work in progress,
and visualizing workflow.
 Extreme Programming (XP): A methodology that focuses on technical excellence
and includes practices like pair programming, test-driven development (TDD),
continuous integration, and frequent releases.

Materials Required:

 Agile tools like Jira, Trello, or any online Scrum/Kanban boards.

 Access to example user stories and backlog items.
 Scrum guide and Kanban resources (available online).
 Whiteboard or digital whiteboard for simulating Scrum and Kanban boards.

Procedure:

1. Introduction to Scrum:
o Begin with a presentation on Scrum, explaining its roles, events, and artifacts.
o Discuss how Scrum sprints work and the importance of each Scrum ceremony.
o Provide examples of Product Backlogs and Sprint Backlogs.
2. Scrum Simulation:
o Sprint Planning: Create a Product Backlog with user stories for a
hypothetical project. Conduct a Sprint Planning meeting to select stories for
the Sprint Backlog.
o Daily Standup: Simulate a few Daily Standup meetings where team members
discuss what they did yesterday, what they will do today, and any blockers
they face.
 o Sprint Review and Retrospective: At the end of the sprint, simulate a Sprint
Review to showcase completed work and a Sprint Retrospective to discuss
what went well and what can be improved.
3. Introduction to Kanban:
o Present the key concepts of Kanban, including work-in-progress (WIP) limits,
continuous delivery, and the visual representation of tasks.
o Set up a Kanban board with columns such as "To Do," "In Progress," and
"Done."
4. Kanban Simulation:
o Populate the Kanban board with tasks and simulate the flow of work through
the board.
o Discuss how WIP limits can help prevent bottlenecks and improve workflow
efficiency.
o Monitor the flow of tasks and discuss any improvements needed based on the
simulation.
5. Introduction to Extreme Programming (XP):
o Introduce XP practices such as pair programming, TDD, and continuous
integration.
o Discuss how these practices help maintain high-quality code and foster
collaboration among developers.
6. XP Simulation:
o Pair up students to practice pair programming on a simple coding task.
o Implement TDD by writing test cases before coding and running tests
frequently.
o Set up a simple continuous integration pipeline to automate the testing and
integration process.
7. Group Discussion and Reflection:
o After the simulations, engage in a group discussion on the strengths and
challenges of each Agile practice.
o Reflect on how these practices can be applied in real-world projects and the
benefits they offer to both developers and stakeholders.
8. Individual Report:
o Each student will write a report summarizing their experience with Scrum,
Kanban, and XP practices.
o The report should include reflections on how these practices improve
collaboration, task management, and product quality.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand and apply Scrum practices, including sprint planning, daily standups,
sprint reviews, and retrospectives.
 Use Kanban to visualize workflow and manage tasks effectively, implementing WIP
limits to improve productivity.
 Apply XP practices such as pair programming, TDD, and continuous integration to
enhance code quality and collaboration.
 Reflect on the strengths and challenges of each Agile practice and how they
contribute to successful project delivery.
Experiment 4: Agile Project Management with User Stories and
Backlogs
Objective:

To understand the importance of user stories and backlogs in Agile project management and
learn how to effectively create, prioritize, and manage them. This experiment will help
students gain practical experience in writing user stories, managing product and sprint
backlogs, and understanding their role in guiding Agile development.

Theory:

In Agile methodologies, user stories and backlogs are fundamental tools for managing work.
A user story is a simple, clear description of a feature from the perspective of the end-user,
typically following the format: "As a [user], I want [feature], so that [benefit]." The Product
Backlog is an ordered list of everything that might be needed in the product, maintained by
the Product Owner. The Sprint Backlog is a subset of the Product Backlog, selected for
completion during a sprint.

Key Concepts:

 User Stories: These are brief, clear descriptions of features or functionality from the
user’s perspective. They are often written on index cards or sticky notes, making them
easy to organize and prioritize.
 Product Backlog: The Product Backlog is a living document that contains all the
desired work items (user stories, tasks, etc.) for a project. It is prioritized by business
value and is the single source of requirements for any changes to be made to the
product.
 Sprint Backlog: The Sprint Backlog contains the set of Product Backlog items
selected for the sprint, as well as a plan for delivering the product increment and
achieving the sprint goal.

Materials Required:

 Access to Agile project management tools like Jira, Trello, or physical index
cards/sticky notes.
 Example project or case study to develop user stories and backlogs.
 Templates for writing user stories and backlog items.

Procedure:

1. Introduction to User Stories:

o Start with a lecture on the importance of user stories in Agile development.
o Explain the structure of a user story: “As a [user], I want [feature], so that
[benefit].”
o Discuss the concept of INVEST criteria for good user stories: Independent,
Negotiable, Valuable, Estimable, Small, and Testable.
2. Writing User Stories:
o Provide students with a case study or example project.
 o Ask students to identify different user personas and write user stories for
various features needed in the project.
o Review and refine the user stories, ensuring they follow the INVEST criteria.
3. Introduction to Product Backlog:
o Explain the concept of a Product Backlog and its role in Agile project
management.
o Discuss how the Product Backlog is prioritized based on factors like business
value, risk, and dependencies.
o Introduce the role of the Product Owner in maintaining and prioritizing the
Product Backlog.
4. Creating and Prioritizing the Product Backlog:
o Using the user stories written earlier, guide students in creating a Product
Backlog.
o Teach students how to prioritize the backlog items based on business value,
technical dependencies, and risk.
o Discuss different prioritization techniques such as MoSCoW (Must have,
Should have, Could have, Won’t have) and Value vs. Effort.
5. Introduction to Sprint Backlog:
o Explain the concept of a Sprint Backlog and how it is derived from the
Product Backlog.
o Discuss the importance of selecting backlog items for a sprint that align with
the sprint goal.
o Introduce the concept of task breakdown, where user stories are broken down
into smaller tasks that can be completed within a sprint.
6. Creating the Sprint Backlog:
o Simulate a Sprint Planning meeting where students select items from the
Product Backlog to create a Sprint Backlog.
o Guide students in breaking down user stories into smaller tasks and estimating
the effort required to complete them.
o Discuss how to track progress throughout the sprint using tools like burndown
charts.
7. Group Activity and Presentation:
o Divide students into small groups and assign each group a set of user stories to
prioritize and include in a Product and Sprint Backlog.
o Each group will present their backlogs and explain their prioritization and task
breakdown decisions.
o Engage in a peer review session where groups provide feedback on each
other’s backlogs.
8. Discussion and Reflection:
o Discuss the challenges faced during backlog creation and prioritization.
o Reflect on how well the user stories captured the requirements and how the
backlogs aligned with the project’s goals.
9. Individual Report:
o Each student will write a report summarizing their experience in writing user
stories, creating and prioritizing backlogs, and reflecting on the importance of
these activities in Agile project management.

Expected Outcome:

By the end of this experiment, students should be able to:

  Write clear and effective user stories that capture the requirements from the user’s
perspective.
 Understand the structure and importance of the Product Backlog and how to prioritize
items within it.
 Create a Sprint Backlog by selecting appropriate user stories and breaking them down
into actionable tasks.
 Reflect on the role of user stories and backlogs in guiding Agile development and
delivering value to the customer.

Experiment 5: Continuous Integration and Continuous Delivery

(CI/CD) in Agile
Objective:

To understand and implement Continuous Integration (CI) and Continuous Delivery (CD)
practices in Agile development. This experiment will provide hands-on experience with
setting up a CI/CD pipeline, automating tests, and deploying software, illustrating how these
practices improve code quality, reduce integration issues, and accelerate delivery.

Theory:

Continuous Integration and Continuous Delivery are core practices in Agile that aim to
ensure that software can be reliably released at any time. CI focuses on integrating code into
a shared repository frequently, with automated builds and tests to detect errors quickly. CD
extends this by automating the release process so that software can be deployed to production
at any time with minimal manual intervention.

Key Concepts:

 Continuous Integration (CI): A practice where developers frequently merge their

code changes into a shared repository, triggering automated builds and tests. This
helps detect integration issues early and ensures that the software remains in a
deployable state.
 Continuous Delivery (CD): A practice where code changes are automatically
prepared for a release to production. This involves automating the build, test, and
deployment processes, ensuring that the software can be released quickly and reliably.
 CI/CD Pipeline: A series of automated steps that take code from development to
deployment, including building the software, running tests, and deploying to
production or staging environments.

Materials Required:

 Access to a version control system (e.g., Git).

 A CI/CD tool or service (e.g., Jenkins, GitLab CI, Travis CI, CircleCI).
 A sample codebase or project repository.
  A testing framework (e.g., JUnit for Java, PyTest for Python).
 Deployment environment (e.g., cloud service like AWS, Azure, or a local server).

Procedure:

1. Introduction to CI/CD:
o Begin with a presentation on the concepts of Continuous Integration and
Continuous Delivery.
o Discuss the benefits of CI/CD, such as early detection of bugs, faster releases,
and improved collaboration among development teams.
2. Setting Up Version Control:
o Set up a version control repository (e.g., on GitHub or GitLab).
o Clone the repository to local machines and create a basic project structure.
o Commit and push initial code to the repository, demonstrating how version
control integrates with CI/CD.
3. Configuring Continuous Integration (CI):
o Choose a CI tool (e.g., Jenkins, GitLab CI) and configure it to work with the
repository.
o Create a CI pipeline that triggers on every code commit.
o Set up automated builds and basic unit tests. For example, use JUnit for Java
projects or PyTest for Python projects.
o Demonstrate how the CI pipeline automatically runs tests and reports results.
4. Implementing Continuous Delivery (CD):
o Extend the CI pipeline to include deployment stages. This could involve
deploying to a staging environment or directly to production, depending on the
project setup.
o Implement automated deployment scripts that push the code to the deployment
environment.
o Configure the pipeline to automatically deploy the application after passing all
tests.
5. Running the CI/CD Pipeline:
o Make code changes, commit them to the repository, and observe the CI/CD
pipeline in action.
o Monitor how the pipeline automatically builds, tests, and deploys the
application.
o Introduce deliberate code errors to demonstrate how the CI pipeline detects
and reports issues.
6. Testing and Monitoring:
o Discuss the importance of automated testing in CI/CD and how it ensures the
quality of the software.
o Introduce additional types of testing that can be integrated into the CI/CD
pipeline, such as integration tests, performance tests, and security scans.
o Set up monitoring tools to track the health and performance of the deployed
application.
7. Group Activity and Discussion:
o Divide students into small groups, each responsible for setting up and
configuring a CI/CD pipeline for a simple project.
o Each group will present their CI/CD setup, explain the pipeline stages, and
discuss any challenges they encountered.
 o
Engage in a class discussion on best practices for CI/CD, the impact on team
productivity, and the role of CI/CD in Agile development.
8. Individual Report:
o Each student will write a report detailing their experience with setting up
CI/CD, including the tools used, challenges faced, and the benefits observed.
o The report should also include reflections on how CI/CD practices improve
the development process and how they can be applied in different project
contexts.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand the concepts and benefits of Continuous Integration and Continuous

Delivery in Agile development.
 Set up and configure a CI/CD pipeline using a version control system and a CI/CD
tool.
 Automate builds, tests, and deployments to ensure that software is always in a
deployable state.
 Reflect on the role of CI/CD in reducing integration issues, accelerating delivery, and
improving software quality.

Experiment 6: Test-Driven Development (TDD) in Agile

Objective:

To understand and apply Test-Driven Development (TDD) within Agile methodologies. This
experiment will give students hands-on experience in writing tests before code, refactoring
code to pass tests, and ensuring that the final product meets the expected quality standards.

Theory:

Test-Driven Development (TDD) is a software development process where developers write

automated test cases before writing the code that needs to pass those tests. TDD follows a
repetitive cycle of writing a test, writing just enough code to pass the test, and then
refactoring the code while keeping all tests passing. This practice helps ensure that the code is
reliable, maintainable, and aligns closely with the specified requirements.

Key Concepts:

 Red-Green-Refactor Cycle: The core practice in TDD where you:

o Red: Write a failing test case for a new feature or functionality.
o Green: Write the minimum amount of code necessary to make the test pass.
o Refactor: Clean up the code while ensuring that all tests continue to pass.
 Unit Testing: Testing individual units or components of a software application in
isolation to ensure that each part functions correctly.
 Test Coverage: The percentage of code covered by automated tests, indicating how
much of the code is tested.
Materials Required:

 Development environment with support for unit testing frameworks (e.g., JUnit for
Java, PyTest for Python, NUnit for C#).
 Access to a version control system (e.g., Git).
 Sample codebase or simple coding tasks to apply TDD.
 Documentation or guides on the selected unit testing framework.

Procedure:

1. Introduction to Test-Driven Development (TDD):

o Begin with a lecture on the principles of TDD and the benefits it offers in
Agile development, such as improved code quality and faster feedback.
o Explain the Red-Green-Refactor cycle and its role in ensuring that code is both
functional and clean.
2. Setting Up the Development Environment:
o Guide students in setting up a development environment that supports unit
testing.
o Install and configure a unit testing framework suitable for the programming
language being used (e.g., JUnit, PyTest, NUnit).
o Set up a version control repository to manage code and tests.
3. Writing the First Test (Red Phase):
o Provide students with a simple problem statement or feature to implement.
o Instruct them to write a test case that fails, based on the requirements of the
feature.
o Emphasize the importance of writing a specific, clear test that reflects the
expected behavior of the code.
4. Writing Code to Pass the Test (Green Phase):
o Have students write the minimum amount of code necessary to make the
failing test pass.
o Run the tests to ensure that the new code passes the test case written in the
previous step.
5. Refactoring the Code (Refactor Phase):
o Once the test is passing, guide students in refactoring the code to improve its
structure, readability, or performance.
o Ensure that the refactoring process does not introduce any new errors by
running the tests frequently.
o Discuss common refactoring techniques and best practices.
6. Repeating the TDD Cycle:
o Instruct students to repeat the Red-Green-Refactor cycle to implement
additional features or handle edge cases.
o Encourage them to write new tests for each new piece of functionality and to
continually refactor their code.
7. Group Activity:
o Divide students into small groups, with each group tasked with implementing
a small application using TDD.
o Each group will work through multiple TDD cycles, adding features
incrementally and ensuring all tests pass at every stage.
o Groups will then present their final applications, discussing the challenges and
benefits they experienced using TDD.
 8. Discussion and Reflection:
o Engage the class in a discussion about the benefits and challenges of TDD.
o Reflect on how TDD influenced their development process, particularly in
terms of code quality and confidence in the codebase.
o Discuss scenarios where TDD might be particularly beneficial and where it
might be less effective.
9. Individual Report:
o Each student will write a report summarizing their experience with TDD,
including the challenges faced, the benefits observed, and how TDD impacted
their coding practices.
o The report should include specific examples of tests written, code refactored,
and the overall quality of the final product.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand and apply the principles of Test-Driven Development in their coding

practices.
 Write effective unit tests that drive the development of new features.
 Use the Red-Green-Refactor cycle to develop reliable, maintainable code.
 Reflect on the impact of TDD on software quality and the development process.

Experiment 7: Agile Estimation and Planning with Story Points

Objective:

To learn and apply Agile estimation techniques, specifically using story points, and to create
effective sprint and release plans. This experiment will help students understand how to
estimate the effort required for user stories, plan sprints, and manage project timelines within
an Agile framework.

Theory:

Agile estimation and planning differ from traditional methods by focusing on relative sizing
and prioritization rather than fixed deadlines. Story points are a common estimation unit in
Agile that represent the relative effort, complexity, and risk of implementing a user story.
These points help teams plan their work and predict the amount of work they can complete in
future sprints.

Key Concepts:

 Story Points: A relative unit of measure used to estimate the effort required to
implement a user story. Story points consider complexity, risk, and the time required.
 Planning Poker: A collaborative estimation technique where team members assign
story points to user stories by consensus.
 Sprint Planning: A meeting where the team selects a set of prioritized user stories
from the product backlog and plans their work for the upcoming sprint.
  Velocity: The average number of story points a team completes in a sprint, used to
predict future capacity.

Materials Required:

 A set of user stories or a sample project backlog.

 Access to Agile project management tools (e.g., Jira, Trello) or physical planning
materials (e.g., index cards, sticky notes).
 Planning Poker cards or a digital tool for collaborative estimation.
 A calculator or spreadsheet for tracking story points and velocity.

Procedure:

1. Introduction to Agile Estimation:

o Begin with a lecture on the importance of estimation in Agile and the role of
story points in planning and tracking progress.
o Discuss how story points differ from time-based estimates and why they are
useful in Agile.
2. Creating User Stories:
o Provide students with a sample project or case study.
o Guide them in writing user stories that clearly describe the functionality to be
implemented.
o Ensure that the user stories are independent, negotiable, valuable, estimable,
small, and testable (INVEST criteria).
3. Introduction to Story Points and Planning Poker:
o Explain how story points are used to estimate the relative effort of user stories.
o Introduce Planning Poker as a technique for team-based estimation, where
each team member assigns story points independently before discussing and
reaching a consensus.
4. Conducting Planning Poker:
o Divide students into small groups, each assigned a set of user stories.
o Have each group conduct a Planning Poker session to estimate the story points
for their user stories.
o Encourage discussion among group members to reach a consensus on the final
estimates.
5. Understanding Velocity:
o Explain the concept of velocity and how it is calculated as the average number
of story points completed in previous sprints.
o Discuss how velocity helps teams predict their capacity for future sprints and
plan accordingly.
6. Sprint Planning:
o Using the estimated story points, guide students in planning a sprint.
o Have them select a set of user stories from the backlog that fits within the
team’s velocity for the sprint.
o Discuss the importance of setting a sprint goal and ensuring that the selected
stories align with that goal.
7. Release Planning:
o Extend the planning process to cover multiple sprints, simulating a release
plan.
 oEstimate the number of sprints required to complete the backlog and achieve a
product release.
o Discuss how to adjust the plan based on team velocity, changing priorities, and
potential risks.
8. Group Activity and Presentation:
o Each group will create a sprint and release plan based on their estimated user
stories.
o Groups will present their plans, discussing the rationale behind their
estimations, sprint goals, and release timelines.
o Engage in a peer review session where groups provide feedback on each
other’s plans.
9. Discussion and Reflection:
o Discuss the challenges and benefits of using story points and Planning Poker
for Agile estimation.
o Reflect on how accurate the estimations were and how they impacted the
sprint and release planning.
o Explore alternative estimation techniques and when they might be more
appropriate.
10. Individual Report:
o Each student will write a report summarizing their experience with Agile
estimation and planning, including the challenges faced, the benefits observed,
and the accuracy of their estimates.
o The report should also include reflections on how estimation influenced the
planning process and the potential for improvement.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand and apply story points to estimate the effort required for user stories.
 Use Planning Poker to facilitate collaborative estimation in Agile teams.
 Create effective sprint and release plans based on estimated story points and team
velocity.
 Reflect on the impact of Agile estimation on project planning and delivery.

Experiment 8: Agile Retrospective and Continuous Improvement

Objective:

To understand the role of retrospectives in Agile development and how they contribute to
continuous improvement. This experiment will involve conducting a simulated Agile
retrospective, identifying areas for improvement, and developing action plans to enhance
team performance and project outcomes.

Theory:

Retrospectives are a key practice in Agile methodologies, particularly in Scrum, where teams
regularly reflect on their work process to identify what went well, what didn’t, and how to
improve. The primary goal of retrospectives is to foster continuous improvement by
encouraging open communication, collaboration, and a commitment to enhancing team
efficiency and product quality.

Key Concepts:

 Agile Retrospective: A recurring meeting where the Agile team reflects on the past
sprint or iteration to identify successes, challenges, and areas for improvement.
 Continuous Improvement (Kaizen): A philosophy that emphasizes the need for
constant, incremental improvement in processes, products, and services.
 SMART Action Items: Specific, Measurable, Achievable, Relevant, and Time-bound
actions identified during a retrospective to address issues or enhance team
performance.

Materials Required:

 Whiteboard or digital collaboration tools (e.g., Miro, MURAL, or a shared

document).
 Retrospective templates or tools (e.g., the “Start, Stop, Continue” format, or “4Ls” –
Liked, Learned, Lacked, Longed For).
 Access to Agile project management tools (e.g., Jira, Trello) for tracking action items.
 Markers, sticky notes, or digital equivalents for brainstorming sessions.

Procedure:

1. Introduction to Agile Retrospectives:

o Begin with a lecture on the importance of retrospectives in Agile and their role
in fostering a culture of continuous improvement.
o Explain different retrospective formats and techniques, such as “Start, Stop,
Continue,” “4Ls,” or the “Sailboat” retrospective.
2. Setting Up the Retrospective:
o Choose a retrospective format that best suits the team’s needs.
o Set the stage by ensuring that all participants understand the purpose of the
retrospective and feel comfortable sharing their thoughts.
o Emphasize the importance of creating a safe, blame-free environment where
team members can speak openly.
3. Conducting the Retrospective:
o Guide students in conducting a simulated Agile retrospective for a past sprint
or project. If possible, use a real or recent project to enhance relevance.
o Begin by asking participants to share what went well during the sprint. These
are the practices or outcomes that should be continued or even amplified in
future sprints.
o Next, ask participants to identify what didn’t go well or what challenges were
faced. Encourage them to focus on process issues rather than individual
performance.
o Finally, facilitate a discussion on areas for improvement, where participants
suggest actionable steps to address the challenges identified.
4. Identifying Action Items:
o Help the team convert the improvement suggestions into SMART action
items.
 o Assign ownership of each action item to specific team members or sub-teams
to ensure accountability.
o Set deadlines for when each action item should be addressed or reviewed.
5. Prioritizing Improvements:
o Guide the team in prioritizing the identified action items based on their
potential impact and the effort required to implement them.
o Ensure that the most critical or impactful actions are prioritized for the next
sprint or iteration.
6. Implementing and Tracking Improvements:
o Integrate the identified action items into the team’s Agile project management
tool for tracking and review in subsequent sprints.
o Encourage the team to regularly revisit these action items during stand-ups or
planning meetings to ensure they are being addressed.
7. Reviewing the Effectiveness of Retrospectives:
o Discuss with students how to measure the effectiveness of retrospectives and
continuous improvement efforts.
o Introduce metrics such as team satisfaction, velocity changes, and defect rates
as potential indicators of improvement.
o Emphasize the importance of consistently conducting retrospectives to
maintain a cycle of continuous improvement.
8. Group Activity:
o Divide students into small groups, each conducting a retrospective on a
different sprint or project scenario.
o Each group will identify strengths, challenges, and improvement areas,
develop action items, and present their findings to the class.
o Facilitate a discussion comparing the different approaches and outcomes of
each group’s retrospective.
9. Discussion and Reflection:
o Reflect on the role of retrospectives in Agile and how they contribute to a
team’s long-term success.
o Discuss common challenges teams may face during retrospectives, such as
lack of participation or focus on the wrong issues, and strategies to overcome
them.
o Explore how the lessons learned from retrospectives can be applied to future
projects or iterations.
10. Individual Report:
o Each student will write a report summarizing their experience with the
retrospective process, including the issues identified, the action items created,
and reflections on the importance of continuous improvement.
o The report should also discuss how the retrospective process could be
improved and how it can be adapted to different project contexts.

Expected Outcome:

By the end of this experiment, students should be able to:

 Understand the purpose and importance of Agile retrospectives in fostering

continuous improvement.
 Facilitate an effective retrospective meeting using different formats and techniques.
 Identify actionable steps to address challenges and improve team performance
  Reflect on the impact of continuous improvement practices on project success and
team dynamics.

Experiment 9: Perform Testing Activities Within an Agile Project

Objective: To understand and implement various testing activities integral to an Agile
project, ensuring software quality through continuous feedback and iterative improvements.

Key Concepts:

1. Continuous Testing:
o Testing is integrated throughout the Agile development cycle, rather than
being a final phase. This includes automated tests, regression tests, and
exploratory tests conducted frequently.
2. Types of Testing:
o Unit Testing: Tests individual components or functions for correctness. Often
driven by Test-Driven Development (TDD) practices.
o Integration Testing: Validates interactions between integrated components or
systems.
o System Testing: Checks the complete and integrated software for compliance
with requirements.
o Acceptance Testing: Ensures the software meets business requirements and is
ready for release. This often includes User Acceptance Testing (UAT).
3. Test Automation:
o Automated tests are created and run frequently to provide quick feedback.
Tools such as Selenium, JUnit, or TestNG may be used.
o Automated testing helps to ensure that new changes do not break existing
functionality.
4. Test-Driven Development (TDD):
o Writing tests before writing the actual code. The cycle involves writing a test,
writing code to pass the test, and then refactoring the code.
5. Behavior-Driven Development (BDD):
o A practice where test scenarios are written in a natural language that describes
the behavior of the system. Tools like Cucumber or SpecFlow are often used.
6. Continuous Integration (CI):
o CI systems automatically run tests every time code is committed, providing
immediate feedback to developers about the impact of their changes.
7. Exploratory Testing:
o Testing performed without a formal test plan, focusing on exploring the
application to find unexpected issues.
8. Test-Driven Deployment (TDD):
o Ensuring that deployment pipelines are robust, with automated deployment
and testing stages to catch issues early.

Procedure:

1. Plan Testing Activities:

 o Collaborate with the team to determine what types of tests are needed based
on user stories, acceptance criteria, and project requirements.
2. Develop Test Cases:
o Write detailed test cases and scenarios for different types of testing (unit,
integration, system, acceptance).
3. Automate Tests:
o Implement automated tests where applicable. Ensure tests are integrated into
the CI/CD pipeline.
4. Execute Tests:
o Regularly run tests as code is developed and integrated. Perform manual and
exploratory testing as needed.
5. Review and Analyze Results:
o Analyze test results to identify and fix bugs. Evaluate the effectiveness of the
tests and make adjustments as needed.
6. Feedback and Improvement:
o Use feedback from testing to improve the code and testing practices. Iterate on
test cases and automation strategies to enhance coverage and efficiency.
7. Documentation:
o Document the testing process, including test cases, results, and any issues
discovered. Maintain records for future reference and continuous
improvement.

Outcome: By performing testing activities within an Agile project, you will ensure that
software quality is maintained throughout the development process. This helps in identifying
and addressing issues early, thereby reducing the risk of defects in the final product and
enhancing overall project efficiency.
DEV OPS
LABORATORY
PROGRAMS

Experiment 1: Build & Test Applications with Continuous

Integration
Objective: To install and configure Jenkins for automating the build, test, and deployment
processes of Java or web applications. This experiment aims to set up a Continuous
Integration (CI) pipeline that ensures code changes are automatically tested and deployed,
improving the development workflow and software quality.

Key Concepts:

1. Continuous Integration (CI):

o The practice of automatically integrating code changes from multiple
contributors into a shared repository several times a day. Each integration is
verified by an automated build and test process to detect issues early.
2. Jenkins:
o An open-source automation server used to implement CI/CD pipelines.
Jenkins automates various stages of software development, including building,
testing, and deploying applications.
3. Build Automation:
o The process of automatically compiling code, running tests, and creating
deployable artifacts. Jenkins can automate this process, reducing manual effort
and ensuring consistency.
4. Testing Automation:
o Running tests automatically as part of the CI pipeline to verify that new code
changes do not introduce defects. This ensures early detection of issues.
5. Deployment Automation:
o Automatically deploying applications to different environments (e.g.,
development, staging, production) as part of the CI pipeline. This helps in
maintaining a consistent deployment process.

Procedure:

1. Install Jenkins:
o Download and install Jenkins on a server or local machine. Follow the
installation instructions for your operating system (e.g., Windows, Linux).
2. Configure Jenkins:
o Access the Jenkins dashboard through a web browser. Perform initial setup
tasks such as configuring the Jenkins URL, setting up administrator access,
and installing essential plugins.
3. Set Up Jenkins Jobs:
o Create a new Jenkins job (project) for your application. This job will define
the build, test, and deployment steps.
 o Build Configuration:
 Define the source code repository (e.g., Git, SVN) from which Jenkins
will pull code.
 Configure the build tools (e.g., Maven for Java projects, npm for
Node.js projects) to compile the code and produce build artifacts.
o Test Configuration:
 Set up Jenkins to run automated tests as part of the build process.
Configure test reporting to view results directly in the Jenkins
dashboard.
o Deployment Configuration:
 Optionally, configure Jenkins to deploy the built application to a server
or cloud platform after a successful build and test.
4. Create a Build Pipeline:
o Use Jenkins Pipelines (either Declarative or Scripted) to define a sequence of
stages for the CI process. Typical stages include Build, Test, and Deploy.
5. Trigger Builds:
o Configure Jenkins to trigger builds automatically upon code commits, pull
requests, or on a scheduled basis.
6. Monitor and Analyze:
o Monitor the Jenkins dashboard to view build status, test results, and
deployment outcomes. Analyze build and test logs to identify and resolve
issues.
7. Iterate and Improve:
o Continuously refine the CI pipeline by adding additional stages, optimizing
build and test processes, and integrating feedback from the development team.

Outcome: By completing this experiment, you will have set up a Jenkins-based CI pipeline
that automates the build, test, and deployment processes for Java or web applications. This
setup will enhance code quality, reduce manual intervention, and accelerate the development
workflow, ensuring that changes are tested and deployed in a consistent and reliable manner.

2. VersionControl - To Perform Version Control on

websites/Software’s using different Version control
toolslike RCS/ CVS/GIT/Mercurial (Any two)

Objective: To perform version control on websites or software using different version

control tools such as RCS, CVS, Git, or Mercurial. This program focuses on managing code
changes, tracking history, and facilitating collaboration among developers.

Key Concepts:

1. Version Control Systems (VCS):

o Tools that track and manage changes to source code over time. They allow
multiple developers to collaborate on a project and keep a history of all
changes made.
2. Version Control Tools:
 o RCS (Revision Control System): An older system designed to manage
changes to text files, mainly used for individual developers or small teams.
o CVS (Concurrent Versions System): An early VCS that supports multiple
developers working concurrently on a project.
o Git: A distributed VCS widely used in modern software development. It
allows for local and remote repositories, branching, and merging.
o Mercurial: A distributed VCS similar to Git, known for its simplicity and
performance.

Procedure:

1. Select Version Control Tools:

o Choose two version control tools from RCS, CVS, Git, or Mercurial for this
program. For instance, you might choose Git and Mercurial for a comparative
study.
2. Install and Set Up Tools:
o RCS/CVS:
 Install the selected tool following the official installation guide.
 Set up a new repository or configure the tool to manage your existing
codebase.
o Git/Mercurial:
 Install Git or Mercurial on your system.
 Initialize a new repository or clone an existing one from a remote
server.
3. Perform Basic Version Control Operations:
o RCS/CVS:
 Add/Commit Changes: Add new files to version control and commit
changes with descriptive messages.
 Update/Checkout: Update your working directory with changes from
the repository or check out different versions of files.
 Revert Changes: Undo changes or revert to previous versions of files.
o Git/Mercurial:
 Clone: Create a local copy of a remote repository (Git) or clone a
repository (Mercurial).
 Commit: Save changes to the local repository with a descriptive
commit message.
 Push/Pull: Push changes to a remote repository (Git) or synchronize
changes (Mercurial).
 Branch/Merge: Create branches to work on different features or bug
fixes, and merge branches into the main codebase.
4. Collaborative Features:
o Branching and Merging:
 Git/Mercurial: Create and switch between branches to work on
separate features or fixes. Merge branches to integrate changes.
o Conflict Resolution:
 Handle conflicts that arise when merging changes from different
branches. Use version control tools to resolve conflicts and ensure
code consistency.
5. Track Changes:
 oView History: Use version control tools to view the history of changes made
to files, including who made the changes and when.
o Diffs: Compare different versions of files to understand what changes were
made between versions.
6. Backup and Restore:
o Backup Repositories: Regularly back up your version control repositories to
prevent data loss.
o Restore Repositories: Retrieve previous versions of files or the entire
repository if needed.
7. Documentation:
o Document the setup, usage, and key differences between the version control
tools used. Include any challenges encountered and how they were resolved.

Outcome: By completing this program, you will have hands-on experience with different
version control tools, understanding how to manage code changes, track project history, and
collaborate effectively. This will enhance your ability to maintain code quality and support
collaborative development efforts.

Program 3: Virtualization & Containerization

Objective: To install and configure Docker for creating and managing containers with
different operating system images. This program focuses on understanding Docker's role in
containerization and virtualization, providing practical experience in managing containers.

Key Concepts:

1. Containerization:
o The process of packaging an application and its dependencies into a container
that can run consistently across different environments. Containers share the
host OS kernel but provide isolated environments for applications.
2. Docker:
o A popular containerization platform that allows you to build, deploy, and
manage containers. Docker simplifies the process of containerizing
applications and their dependencies.
3. Docker Images:
o Pre-built snapshots of an application and its environment. Images serve as the
blueprint for creating Docker containers.
4. Docker Containers:
o Instances of Docker images running as isolated processes on the host
operating system. Containers provide a lightweight and consistent
environment for applications.

Procedure:

1. Install Docker:
o On Linux:
  Update the package index and install Docker using your package
manager (e.g., apt, yum).
 For example, on Ubuntu: sudo apt-get update && sudo apt-get
install docker.io
o On Windows/Mac:
 Download and install Docker Desktop from the Docker website.
 Follow the installation wizard to set up Docker on your system.
2. Start Docker:
o Ensure that the Docker service is running. On Linux, you might use sudo
systemctl start docker. On Windows/Mac, Docker Desktop should start
automatically.
3. Verify Docker Installation:
o Run docker --version to check the installed Docker version.
o Use docker info to get detailed information about your Docker installation
and environment.
4. Pull Docker Images:
o Use the docker pull command to download images from Docker Hub or
other repositories.
o For example: docker pull ubuntu:latest to pull the latest Ubuntu image.
5. Create and Run Containers:
o Use the docker run command to create and start a container from an image.
o For example: docker run -it ubuntu:latest /bin/bash to start an
interactive shell in an Ubuntu container.
6. Manage Containers:
o List Containers: Use docker ps to list running containers and docker ps -
a to list all containers (running and stopped).
o Stop Containers: Use docker stop <container_id> to stop a running
container.
o Remove Containers: Use docker rm <container_id> to remove stopped
containers.
7. Create Custom Docker Images:
o Dockerfile: Create a Dockerfile that defines the environment and application
setup. The Dockerfile contains instructions for building an image.
o Build Image: Use docker build -t <image_name>:<tag> . to build an
image from the Dockerfile.
o Push Image: Optionally, push the image to a Docker repository using docker
push <image_name>:<tag>.
8. Explore Docker Hub:
o Browse Docker Hub (hub.docker.com) for available images and explore
various containerized applications and operating system images.
9. Advanced Docker Configuration:
o Volumes: Use Docker volumes to manage persistent data across container
restarts and deployments.
o Networking: Configure Docker networking to enable communication
between containers or between containers and the host machine.
10. Documentation:
o Document the Docker installation process, image creation, container
management, and any challenges encountered. Include practical examples and
use cases.
Outcome: By completing this program, you will gain practical experience in using Docker
for containerization. You’ll understand how to install and configure Docker, manage
containers, and create custom images. This knowledge will enable you to leverage Docker for
building, deploying, and managing applications in a consistent and efficient manner.

DevOps Program 4: Virtualization & Containerization

Objective: To build, deploy, and manage web or Java applications using Docker. This
program focuses on practical skills for containerizing applications, deploying them with
Docker, and managing their lifecycle.

Key Concepts:

1. Containerization of Applications:
o The process of packaging an application along with its dependencies into a
Docker container. This ensures that the application runs consistently across
different environments.
2. Docker Workflow:
o Involves building a Docker image, running a container from that image, and
managing the container throughout its lifecycle.
3. Dockerfile:
o A script containing instructions for building a Docker image. It specifies the
base image, application dependencies, and configuration steps.
4. Docker Compose:
o A tool for defining and running multi-container Docker applications. It uses a
YAML file to configure application services, networks, and volumes.

Procedure:

1. Create a Dockerfile for Your Application:

o Web Application (e.g., Node.js, Python Flask):
 Create a Dockerfile in the root directory of your application.
 Example Dockerfile for a Node.js application

CODE:

# Use an official Node.js runtime as a parent image

FROM node:14

# Set the working directory in the container

WORKDIR /app
# Copy package.json and package-lock.json

COPY package*.json ./

# Install application dependencies

RUN npm install

# Copy the rest of the application code

COPY . .

# Expose the port the app runs on

EXPOSE 3000

# Define the command to run the application

CMD ["node", "app.js"]

Java Application:

• Create a Dockerfile for a Java application.

• Example Dockerfile for a Java application

CODE:

# Use an official Java runtime as a parent image

FROM openjdk:11-jre

# Set the working directory in the container

WORKDIR /app

# Copy the JAR file into the container

COPY target/myapp.jar /app/myapp.jar

# Expose the port the app runs on

EXPOSE 8080

# Define the command to run the application CMD ["java", "-jar", "myapp.jar"]

1. Build the Docker Image:

o Navigate to the directory containing the Dockerfile.
o Build the Docker image using the docker build command:

CODE:

docker build -t myapp:latest .

2. Run the Docker Container:

o Start a container from the built image using the docker run command:

CODE:
docker run -d -p 8080:8080 --name myapp-container myapp:latest

-d runs the container in detached mode.

-p maps the container port to the host port.

3. Manage Docker Containers:

o List Containers: Use docker ps to view running containers.
o Stop a Container: Use docker stop myapp-container to stop a running
container.
o Remove a Container: Use docker rm myapp-container to remove a
stopped container.
4. Use Docker Compose (Optional):
o Create a docker-compose.yml file to define multi-container applications.
o Example docker-compose.yml for a web application:

CODE:
version: '3'

services:
 web:
image: myapp:latest
ports:
- "8080:8080"

o Start the application using docker-compose up and stop it with docker-

compose down.
5. Testing and Debugging:
o Access Logs: Use docker logs myapp-container to view application logs.
o Connect to Container: Use docker exec -it myapp-container
/bin/bash to access the container’s shell for debugging.
6. Documentation:
o Document the Dockerfile configuration, image build process, container
management, and any challenges faced. Include examples and best practices
for deploying and managing applications with Docker.

Outcome: By completing this program, you will be able to effectively build, deploy, and
manage web or Java applications using Docker. You’ll gain hands-on experience in
containerizing applications, running and managing Docker containers, and using Docker
Compose for complex setups. This will enhance your ability to streamline application
deployment and ensure consistent environments across different stages of development and
production.

Program 5: Software Configuration Management

Objective: To install and configure software configuration management tools such as Chef,
Puppet, Ansible, or SaltStack. This program focuses on automating the configuration and
management of infrastructure, ensuring consistency and scalability across environments.

Key Concepts:

1. Configuration Management:
o The process of managing and automating the configuration of systems,
servers, and applications. It ensures that infrastructure is consistent, reliable,
and easily reproducible.
2. Configuration Management Tools:
o Chef: An open-source automation platform that manages infrastructure as
code using recipes and cookbooks.
o Puppet: An open-source configuration management tool that automates the
provisioning and management of infrastructure using manifests.
o Ansible: An open-source automation tool that simplifies configuration
management, application deployment, and task automation using playbooks.
o SaltStack: An open-source tool for managing and automating infrastructure
using states and formulas.
Procedure:

1. Choose a Configuration Management Tool:

o Select one or more tools (Chef, Puppet, Ansible, SaltStack) to focus on for this
program.
2. Install the Tool:
o Chef:
 Install Chef Workstation: Download and install Chef Workstation
from the Chef website.
 Install Chef Infra Server (Optional): For centralized management,
install Chef Infra Server on a server.
 Install Chef Client: Install Chef Client on nodes (machines) that will
be managed.
o Puppet:
 Install Puppet Agent: Download and install Puppet Agent from the
Puppet website.
 Install Puppet Server (Optional): For centralized management,
install Puppet Server on a server.
o Ansible:
 Install Ansible: Use a package manager to install Ansible. For
example, on Ubuntu: sudo apt-get install ansible.
o SaltStack:
 Install Salt Master: Install Salt Master on a server using package
managers or the SaltStack website.
 Install Salt Minion: Install Salt Minion on nodes that will be
managed.
3. Configure the Tool:
o Chef:
 Create Cookbooks: Write cookbooks that define the desired state of
your infrastructure.
 Write Recipes: Define recipes within cookbooks to configure specific
aspects of your infrastructure.
 Use the Knife Tool: Manage nodes and deploy cookbooks using the
knife command-line tool.
o Puppet:
 Write Manifests: Create Puppet manifests that describe the desired
configuration of your infrastructure.
 Define Modules: Organize manifests into modules for reusability and
clarity.
 Use Puppet Agent: Apply configurations to nodes using the puppet
agent command.
o Ansible:
 Write Playbooks: Create Ansible playbooks that define tasks and
configurations for your infrastructure.
 Use Inventory Files: Define hosts and groups in inventory files to
target specific machines.
 Run Playbooks: Execute playbooks using the ansible-playbook
command.
o SaltStack:
  Write States: Define states that describe the desired configuration of
your infrastructure.
 Use Salt Formulas: Utilize pre-built Salt formulas for common
configurations.
 Run Commands: Apply states to nodes using the salt command.
4. Automate Configuration:
o Define and automate configurations for servers, applications, and services
using the chosen tool's syntax and features.
5. Testing and Validation:
o Test configurations in a staging environment before applying them to
production. Validate that configurations are applied correctly and troubleshoot
any issues.
6. Documentation:
o Document the installation and configuration process for the chosen tool(s).
Include examples of configuration files, playbooks, or manifests. Describe
best practices and any challenges encountered.

Outcome: By completing this program, you will gain practical experience in using
configuration management tools to automate and manage infrastructure. You will understand
how to install and configure tools like Chef, Puppet, Ansible, or SaltStack, and apply
configurations consistently across environments. This will help streamline infrastructure
management, reduce manual configuration errors, and improve overall efficiency.

. Program 6: Provisioning
Objective: To perform software configuration management and provisioning using tools like
Chef, Puppet, Ansible, or SaltStack. This program focuses on automating the setup and
management of infrastructure, ensuring that systems are provisioned and configured
consistently and efficiently.

Key Concepts:

1. Provisioning:
o The process of setting up and configuring hardware or virtual resources to
meet specific requirements. This includes creating servers, installing software,
and configuring system settings.
2. Configuration Management:
o Managing and automating the configuration of systems, servers, and
applications. This ensures that systems are configured consistently and can be
replicated easily.
3. Infrastructure as Code (IaC):
o Managing and provisioning infrastructure through code. This approach
automates the setup of environments and ensures consistency across different
stages of development and production.

Procedure:
1. Choose a Tool for Provisioning:
o Select one or more tools (Chef, Puppet, Ansible, SaltStack) for this program.
Each tool has its approach to provisioning and configuration management.
2. Install and Configure the Tool:
o Chef:
 Install Chef Workstation: Download and install Chef Workstation.
 Set Up Chef Infra Server (Optional): Install Chef Infra Server for
centralized management.
 Install Chef Client: Install Chef Client on the nodes you want to
manage.
o Puppet:
 Install Puppet Agent: Install Puppet Agent on the nodes.
 Set Up Puppet Server (Optional): Install Puppet Server for
centralized management.
o Ansible:
 Install Ansible: Install Ansible on a management machine.
 Configure Inventory: Define the inventory file with the list of nodes
to manage.
o SaltStack:
 Install Salt Master: Install Salt Master on a central server.
 Install Salt Minion: Install Salt Minion on the nodes to be managed.
3. Define Infrastructure as Code:
o Chef:
 Create Cookbooks: Write cookbooks that define the desired state of
your infrastructure.
 Write Recipes: Define recipes to specify the configuration tasks (e.g.,
installing software, managing services).
 Use Roles and Environments: Organize cookbooks into roles and
environments for better management.
o Puppet:
 Write Manifests: Create Puppet manifests that describe the
configuration of your infrastructure.
 Define Modules: Organize configuration code into modules for
reusability.
 Use Hiera (Optional): Use Hiera for hierarchical data lookup to
manage configuration values.
o Ansible:
 Write Playbooks: Create playbooks to define the steps for
provisioning and configuring systems.
 Use Roles: Organize playbooks into roles to reuse common
configuration tasks.
 Configure Inventory: Specify the inventory file with target nodes and
groups.
o SaltStack:
 Write States: Define states in Salt to describe the desired
configuration of systems.
 Use Formulas: Utilize Salt formulas for common configurations.
 Configure Pillars (Optional): Use pillars to manage sensitive or
environment-specific data.
4. Provision and Configure Systems:
 o Run Configuration Code:
 Chef: Use chef-client to apply cookbooks and recipes to nodes.
 Puppet: Use puppet agent to apply manifests to nodes.
 Ansible: Use ansible-playbook to execute playbooks on target
nodes.
 SaltStack: Use salt to apply states to managed nodes.
5. Test and Validate:
o Test the provisioning and configuration in a staging environment before
applying it to production.
o Validate that the configuration is applied correctly and troubleshoot any
issues.
6. Manage and Update:
o Continuous Updates: Continuously update and manage the configuration
code to handle changes and improvements.
o Version Control: Use version control to manage configuration code changes
and track revisions.
7. Documentation:
o Document the provisioning and configuration process, including code
examples, setup instructions, and best practices. Include any challenges faced
and solutions implemented.

Outcome: By completing this program, you will gain practical experience in using
configuration management tools to automate the provisioning and configuration of
infrastructure. You will understand how to use tools like Chef, Puppet, Ansible, or SaltStack
to set up and manage systems consistently, improving efficiency and reducing manual
configuration efforts.