💡 Pro Tip: Hands-on practice is essential. Build real projects alongside each module.
Welcome to the very first module of our Certified DevOps Engineer course! This module is called "Introduction to DevOps: What, Why, and How." In this module, we will learn all about DevOps — what it is, why it is important, and how it helps people build better software faster.
DevOps is a very important topic in the world of technology. It helps teams work together, build software more quickly, and make sure that software works properly. Think of DevOps as a way to make the whole process of creating software smoother and more fun!
Hello and welcome! This is Module 1 of the Certified DevOps Engineer course. In this module, we are going to start our journey into the world of DevOps.
But first, let us think about something we all know — building things. When you build something, like a house or a treehouse, you need a plan, you need materials, and you need people to help you. Building software (like the apps on your phone or the websites you visit) is similar. People work together to create software, and they need to work in a way that is organized and efficient.
DevOps is a way of working together to build software. It brings together two groups of people: the "Developers" (who write the code) and the "Operations" people (who make sure the software runs properly on computers and servers). By working together, they can build better software, faster.
In this module, we will learn all about DevOps. We will use simple words, fun stories, and lots of examples. By the end of this module, you will understand what DevOps is and why it is so important in the technology world.
So, are you ready? Let us dive in and discover the amazing world of DevOps!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company that built software for schools. The company was called "EduTech Solutions."
EduTech Solutions had two teams of people. One team was called the "Developers." Their job was to write the code — the instructions that make the software work. They were very creative and loved building new features.
The other team was called the "Operations" team. Their job was to make sure the software ran properly on the computers and servers. They made sure the software was available for students and teachers to use.
Here was the problem: the two teams did not talk to each other very much. The Developers would write code and then "throw it over the wall" to the Operations team. The Operations team would then try to make it work, but they often had problems because they did not understand the code.
The Developers wanted to add new features quickly. The Operations team wanted to make sure everything was stable and did not break. They had different goals, and they did not work well together.
One day, the company lost a big customer because the software kept breaking. The customer was frustrated and went to a competitor. The company knew something had to change.
That is when the company discovered DevOps. DevOps is a way of working that brings Developers and Operations together. They start talking to each other, sharing ideas, and working as one team.
With DevOps, the Developers and Operations people started meeting regularly. They planned together, built together, and solved problems together. The software became more reliable, and they could add new features much faster.
The company grew and became very successful. And it all started because they learned to work together through DevOps.
This story shows us how important it is for different teams to work together. DevOps helps teams do exactly that. Let us learn more about this amazing way of working!
DevOps is a way of working where the people who build software (Developers) and the people who run the software (Operations) work together as one team.
The word "DevOps" comes from combining two words: Dev (short for Development) and Ops (short for Operations).
DevOps is important because it helps teams build software faster, with fewer problems. When Developers and Operations work together, they can catch mistakes early and fix them quickly. This means better software for everyone!
Imagine you are building a treehouse with your friends. Some of your friends are good at designing (the Developers). Others are good at building and making sure the treehouse is safe (the Operations team).
If the designers do not talk to the builders, they might design a treehouse that is impossible to build. Or the builders might build it differently than the designers wanted. But if they work together, they can build an amazing treehouse that everyone loves!
DevOps is exactly the same but for building software. It brings the "designers" (Developers) and the "builders" (Operations) together.
A company called "PayNaija" builds a payment app. The Developers write the code for the app. The Operations team makes sure the app runs on the servers. With DevOps, they work together so the app is always available and works perfectly.
Imagine your school is putting on a play. The scriptwriters (Developers) write the script. The stage crew (Operations) sets up the stage and lights. If they work together, the play is a success. If they do not talk, the play might be a disaster!
Your family is planning a vacation. Some people plan the activities (Developers). Others handle the travel and accommodation (Operations). If you all work together, you have a great vacation. If not, things can go wrong.
A Nigerian bank uses DevOps to build its mobile banking app. The Developers and Operations teams work together. The app is updated frequently with new features, and it rarely crashes. Customers are happy!
WHAT IS DEVOPS?
+-------------------+ +-------------------+
| DEVELOPMENT | | OPERATIONS |
| (Developers) | | (Ops Team) |
| | | |
| Write code | | Run software |
| Build features | | Keep it running |
| Create new stuff | | Fix problems |
+-------------------+ +-------------------+
| |
| DEVOPS BRINGS |
| THEM TOGETHER! |
| |
V V
+------------------------------------------+
| |
| DEVOPS TEAM |
| |
| Developers + Operations = Better, |
| faster software! |
| |
+------------------------------------------+
DevOps is a way of working where Developers and Operations people work together as one team. It helps teams build better software, faster.
Why we need DevOps: We need DevOps because the old way of building software had many problems. Developers and Operations did not work together, and this caused delays, mistakes, and unhappy customers.
Understanding why we need DevOps helps us appreciate how much better it is to work together. It shows us the problems that DevOps solves.
Think about a relay race. In a relay race, one runner passes a baton to the next runner. If they do not pass it smoothly, they drop the baton and lose the race.
In the old way of building software, Developers would "pass the baton" (the code) to Operations. But they did not pass it smoothly. The Operations team often could not understand the code, and things broke. DevOps is like teaching the runners to pass the baton perfectly every time.
| Problem | What It Meant |
|---|---|
| Slow Releases | It took months or even years to release new software. |
| Many Mistakes | Software often had bugs because teams did not test together. |
| Finger-Pointing | Developers blamed Operations when things broke, and vice versa. |
| Hard to Fix | When something broke, it took a long time to fix because no one knew the whole picture. |
| Unhappy Customers | Because software was slow and buggy, customers were not happy. |
A Nigerian e-commerce company used to release new features only once a year. Customers were frustrated because the app did not have the latest features. After adopting DevOps, they release new features every week. Customers are much happier.
Your class is working on a group project. If everyone works alone and does not share their work, the project will be a mess. But if everyone works together and shares ideas, the project is great. DevOps is like working together on a group project.
Your family is planning a big dinner. If everyone cooks without talking to each other, you might end up with three different types of rice and no meat. But if you plan together, you make a wonderful meal. DevOps is like planning together.
A Nigerian bank used to take months to update its mobile app. Customers complained about outdated features. After adopting DevOps, the bank can update the app in days. Customers are happier, and the bank keeps more customers.
THE PROBLEM BEFORE DEVOPS
DEVELOPMENT OPERATIONS
+-------------------+ +-------------------+
| Write code | | Run software |
| Build features | | Fix problems |
| | | |
| "We are done!" | ======> | "This does not |
| | throw | work!" |
| | over | |
| | wall | "It is the |
| | | developer's |
| | | fault!" |
+-------------------+ +-------------------+
RESULT: SLOW, BUGGY, UNHAPPY CUSTOMERS
THE SOLUTION: DEVOPS!
DEVELOPMENT AND OPERATIONS WORK TOGETHER
+------------------------------------------+
| |
| "Let us work together!" |
| "We will build it together!" |
| "We will fix problems together!" |
| |
| RESULT: FAST, RELIABLE, HAPPY CUSTOMERS |
| |
+------------------------------------------+
We need DevOps because the old way of building software had many problems. Developers and Operations did not work together, causing slow releases, many mistakes, and unhappy customers. DevOps solves all these problems.
The history of DevOps is the story of how DevOps came to be. It started because people realized that the old way of building software was not working well.
Understanding the history of DevOps helps us understand why it is so important today. It shows us that DevOps was created to solve real problems.
Imagine you are playing a video game. The game has two teams. One team designs the levels, and the other team makes sure the game runs smoothly. But the two teams never talk to each other. The level designers make levels that are too hard for the game engine to run. The game crashes, and players are unhappy.
The game developers realize they need to work together. They start meeting and talking. They plan together. The game becomes amazing. That is the story of how DevOps started!
| Year | Event | What Happened |
|---|---|---|
| 2000s | Agile Movement | People realized that building software in a flexible, iterative way was better than doing everything at once. |
| 2009 | First DevOps Conference | A conference called "Velocity 2009" talked about how Development and Operations should work together. |
| 2010-2013 | DevOps Grows | More companies started using DevOps. Tools like Jenkins, Ansible, and Docker were created to help. |
| 2014-2016 | DevOps Becomes Mainstream | DevOps became a standard way of working for many tech companies. |
| 2017-Present | DevOps Everywhere | DevOps is now used by companies all over the world, including many in Nigeria. |
A company called "Flutterwave" (a Nigerian fintech company) started using DevOps to build its payment platform. By working together, they built a platform that processes millions of transactions every day.
Your school used to plan events with teachers and students working separately. Now, they have meetings where everyone shares ideas. The events are much better because everyone works together.
Your family used to plan vacations with everyone making their own plans. Now, you have a family meeting where everyone shares ideas. The vacations are much more fun because everyone works together.
A Nigerian company called "Andela" uses DevOps to build software for clients all over the world. By working together, they deliver high- quality software quickly.
THE HISTORY OF DEVOPS TIMELINE
2000s
+-------------------+
| Agile Movement |
| People want to |
| work flexibly |
+-------------------+
|
V
2009
+-------------------+
| First DevOps |
| Conference |
| "Velocity 2009" |
+-------------------+
|
V
2010-2013
+-------------------+
| DevOps Grows |
| New tools like |
| Jenkins, Docker |
+-------------------+
|
V
2014-2016
+-------------------+
| DevOps Becomes |
| Mainstream |
| Many companies |
| adopt it |
+-------------------+
|
V
2017-Present
+-------------------+
| DevOps Everywhere|
| Used worldwide |
| Including Nigeria|
+-------------------+
DevOps started because people realized that working together was better than working separately. It has grown from an idea in 2009 to a standard way of working today.
The DevOps Lifecycle is the series of steps that a team follows to build, test, release, and monitor software. It is like a roadmap for building software.
The DevOps Lifecycle shows us all the stages of building software. It helps us understand the complete picture and see how DevOps helps at every stage.
Imagine you are baking a cake. You have a recipe that tells you every step: gather ingredients, mix them, bake the cake, and serve it. The DevOps Lifecycle is like a recipe for building software. It tells you every step from start to finish.
| Stage | What Happens | Simple Example |
|---|---|---|
| Plan | Decide what to build and how to build it | Planning the cake recipe and ingredients |
| Code | Write the software code | Mixing the cake ingredients |
| Build | Turn the code into a working program | Putting the cake in the oven |
| Test | Check that the software works correctly | Tasting the cake to make sure it is good |
| Release | Prepare the software to be used by customers | Decorating the cake and putting it on a plate |
| Deploy | Make the software available to users | Serving the cake to your family |
| Operate | Keep the software running properly | Making sure the cake is stored properly |
| Monitor | Watch the software to find problems | Checking if the cake is still fresh |
A Nigerian company building a mobile app follows the DevOps Lifecycle. They plan the features, write the code, build the app, test it, release it, deploy it to app stores, operate it, and monitor it for problems.
Your class is making a school newspaper. You plan the articles, write them, put them together, check for errors, print them, distribute them, and check if students like them. That is the lifecycle of a newspaper!
Your family is planning a party. You plan the party, prepare the food, set up the decorations, check everything is ready, host the party, and clean up afterwards. That is a lifecycle!
A Nigerian e-commerce company follows the DevOps Lifecycle to build its website. They plan new features, code them, build them, test them, release them, deploy them, operate the website, and monitor for issues.
THE DEVOPS LIFECYCLE
+--------------------------------------------------+
| |
| PLAN |
| (Decide what to build) |
| | |
| V |
| CODE |
| (Write the software) |
| | |
| V |
| BUILD |
| (Turn code into a program) |
| | |
| V |
| TEST |
| (Check it works) |
| | |
| V |
| RELEASE |
| (Prepare for users) |
| | |
| V |
| DEPLOY |
| (Make it available to users) |
| | |
| V |
| OPERATE |
| (Keep it running) |
| | |
| V |
| MONITOR |
| (Watch for problems) |
| | |
| V |
| (Go back to PLAN and repeat!) |
| |
+--------------------------------------------------+
The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
Core DevOps Principles are the main ideas that guide how DevOps works. They are like the rules of the game.
Principles are important because they guide our actions. When we know the principles, we know how to do things the right way.
Imagine you are playing football. There are rules like "no hands" and "score a goal to win." These rules guide how you play. DevOps principles are the rules that guide how teams build software together.
There are three main principles in DevOps. They are called "The Three Ways." Let us learn about each one.
Definition: The First Way is about making the flow of work from Development to Operations fast and smooth.
Simple Explanation: Imagine a river. The water flows smoothly from the mountains to the ocean. The First Way is about making the work flow smoothly from the developer to the user.
Definition: The Second Way is about getting feedback quickly. When something goes wrong, we need to know immediately so we can fix it.
Simple Explanation: Imagine you are cooking. If you taste the food while cooking, you can add more salt if it needs it. If you wait until the end, it might be too late. The Second Way is about tasting the food early and often.
Definition: The Third Way is about always learning and improving. We should always look for ways to do things better.
Simple Explanation: Imagine you are playing a video game. Every time you lose, you learn something new. You try again and get better. The Third Way is about always learning and improving.
A Nigerian company follows the Three Ways. They release software quickly (Flow), they get feedback from users quickly (Feedback), and they always look for ways to improve (Continuous Learning).
Your school project team follows the Three Ways. You work smoothly together (Flow), you give each other feedback (Feedback), and you learn from mistakes (Continuous Learning).
Your family plans a party. You work together smoothly (Flow), you ask guests for feedback (Feedback), and you learn what to do better next time (Continuous Learning).
A Nigerian company building a delivery app follows the Three Ways. They release updates quickly (Flow), they get feedback from customers (Feedback), and they always improve (Continuous Learning).
THE THREE WAYS OF DEVOPS
+--------------------------------------------------+
| |
| THE FIRST WAY: FLOW |
| +------------------------------------+ |
| | Make work flow smoothly from | |
| | Development to Operations | |
| | "Keep the river flowing" | |
| +------------------------------------+ |
| | |
| V |
| THE SECOND WAY: FEEDBACK |
| +------------------------------------+ |
| | Get feedback quickly | |
| | "Taste the food while cooking" | |
| +------------------------------------+ |
| | |
| V |
| THE THIRD WAY: CONTINUOUS LEARNING |
| +------------------------------------+ |
| | Always learn and improve | |
| | "Get better every day" | |
| +------------------------------------+ |
| |
| TOGETHER, THEY MAKE DEVOPS WORK! |
| |
+--------------------------------------------------+
The core DevOps principles are called the Three Ways. The First Way is about smooth flow. The Second Way is about quick feedback. The Third Way is about continuous learning.
DevOps culture is the way people think and behave when they work in a DevOps team. It is about working together, sharing ideas, and helping each other.
Culture is important because it affects how people work. A good culture makes people happy and productive. A bad culture makes people unhappy and unproductive.
Imagine you are on a sports team. A good team cheers for each other, helps each other, and celebrates together. A bad team blames each other and does not work together. DevOps culture is like being on a good sports team.
| Element | What It Means |
|---|---|
| Collaboration | Working together, sharing ideas, and helping each other |
| Communication | Talking to each other openly and honestly |
| Trust | Believing that others will do their best work |
| Blame-Free | When something goes wrong, we fix it instead of blaming someone |
| Continuous Improvement | Always looking for ways to get better |
| Shared Goals | Everyone works towards the same goals |
A Nigerian company has a DevOps culture. The team meets daily, shares what they are working on, and helps each other. When something breaks, they fix it together instead of blaming anyone.
Your classroom has a good culture. Students help each other with homework, share supplies, and celebrate each other's successes.
Your family has a good culture. Everyone helps with chores, listens to each other, and supports each other.
A Nigerian tech startup has a DevOps culture. The Developers and Operations people sit together, talk openly, and work as one team. They are very successful because of their culture.
DEVOPS CULTURE
+--------------------------------------------------+
| |
| 🗣️ COMMUNICATION |
| Talk openly and honestly |
| |
| 🤝 COLLABORATION |
| Work together, share ideas |
| |
| ❤️ TRUST |
| Believe in each other |
| |
| ✅ BLAME-FREE |
| Fix problems, not blame people |
| |
| 📈 CONTINUOUS IMPROVEMENT |
| Always get better |
| |
| 🎯 SHARED GOALS |
| Everyone works towards the same goal |
| |
| TOGETHER = DEVOPS SUCCESS! 🚀 |
| |
+--------------------------------------------------+
DevOps culture is about working together, sharing ideas, and helping each other. Key elements include collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Agile is a way of building software where teams work in short cycles (called "sprints") and deliver small pieces of working software frequently. It is about being flexible and responding to change.
DevOps takes Agile and extends it. It brings in the Operations team so that the whole process of building and running software is smooth.
Understanding Agile helps us understand where DevOps came from. DevOps is like the "next step" after Agile.
Imagine you are building a house. The old way was to plan everything perfectly and build the whole house at once. Agile is like building the house room by room. You build the bedroom, then the kitchen, then the living room. You can change things as you go.
DevOps is like having the builders and the maintenance team work together. While the builders are building the house, the maintenance team is making sure everything is working properly. They work together from the start.
| Aspect | Agile | DevOps |
|---|---|---|
| Focus | Building software quickly and flexibly | Building and running software together |
| Teams | Development team | Development + Operations teams |
| Goal | Deliver working software frequently | Deliver working software frequently AND keep it running |
| Timeframe | Short sprints (2-4 weeks) | Continuous delivery (always ready to release) |
A Nigerian company uses Agile to build its app. They release new features every two weeks. They also use DevOps to make sure the app runs smoothly for all users.
Your class uses Agile to plan a school event. You plan a little bit at a time and adjust as you go. You also use DevOps by having the teachers and students work together.
Your family uses Agile to plan a vacation. You plan a little bit at a time and adjust. You also use DevOps by having everyone work together on the plan.
A Nigerian fintech company uses Agile to build new features quickly. They also use DevOps to make sure the features work properly for customers. Together, Agile and DevOps help them grow fast.
AGILE + DEVOPS = SUCCESS!
AGILE:
+--------------------------------------------------+
| Build software in short cycles (sprints) |
| Deliver small pieces frequently |
| Respond to change quickly |
| Focus on Development |
+--------------------------------------------------+
|
V
DEVOPS:
+--------------------------------------------------+
| Takes Agile and adds Operations |
| Development + Operations work together |
| Build AND run software |
| Continuous delivery and monitoring |
+--------------------------------------------------+
|
V
RESULT:
+--------------------------------------------------+
| Faster, better, more reliable software! |
| Happy developers, happy operations, happy users! |
+--------------------------------------------------+
Agile is a way of building software in short cycles. DevOps extends Agile by bringing in the Operations team so that building and running software are done together.
The benefits of DevOps are all the good things that happen when a team uses DevOps. These include faster releases, fewer problems, and happier customers.
Understanding the benefits helps us see why DevOps is so valuable. It helps us understand why so many companies are adopting DevOps.
Imagine you have a car. If you take good care of it, it runs smoothly, gets you where you need to go, and lasts a long time. DevOps is like taking good care of your software. The benefits are: it runs smoothly, it works well, and it lasts a long time.
| Benefit | What It Means |
|---|---|
| Faster Releases | Software is released more quickly, so users get new features sooner |
| Fewer Problems | Bugs and issues are caught and fixed early, so software is more reliable |
| Better Collaboration | Teams work together, share ideas, and help each other |
| Happy Customers | Because software works well and has new features, customers are happy |
| Less Stress | Teams work together to solve problems, so there is less stress |
| Continuous Improvement | Teams always look for ways to get better |
A Nigerian company adopted DevOps. Before DevOps, they released updates once a year. After DevOps, they release updates every week. Their customers are much happier.
Your school uses DevOps for its website. They release updates quickly, the website rarely breaks, and students and parents are happy.
Your family uses DevOps principles to plan events. Everyone works together, problems are fixed quickly, and events are successful.
A Nigerian e-commerce company uses DevOps. They release new features quickly, their website is very reliable, and their customers love them. The company has grown a lot because of DevOps.
THE BENEFITS OF DEVOPS
+--------------------------------------------------+
| |
| 🚀 FASTER RELEASES |
| New features reach users quickly |
| |
| 🐛 FEWER PROBLEMS |
| Bugs are caught and fixed early |
| |
| 🤝 BETTER COLLABORATION |
| Teams work together happily |
| |
| 😊 HAPPY CUSTOMERS |
| Users love the software |
| |
| 🧘 LESS STRESS |
| Teams are calm and effective |
| |
| 📈 CONTINUOUS IMPROVEMENT |
| Always getting better |
| |
| ALL BECAUSE OF DEVOPS! 🎉 |
| |
+--------------------------------------------------+
DevOps has many benefits. It leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
Who uses DevOps: DevOps is used by many different types of organizations. From small startups to big companies, from tech giants to banks, and even schools and governments.
Knowing who uses DevOps shows us that DevOps is not just for one type of organization. It can be used by anyone who builds software.
Imagine a toolbox. DevOps is like a toolbox that anyone can use. Whether you are building a small birdhouse or a big skyscraper, the toolbox has the tools you need. DevOps is like that — it works for all types of software projects.
A Nigerian bank uses DevOps to build its mobile banking app. The app is updated frequently and works reliably. Customers can transfer money, pay bills, and check balances easily.
Your school uses a learning platform to share lessons and assignments. The platform is built using DevOps principles. It is always available and has new features regularly.
Your family uses a family calendar app to coordinate activities. The app is built using DevOps. It is reliable and gets new features often.
Many Nigerian companies use DevOps. Flutterwave, Paystack, Andela, Interswitch, and many others use DevOps to build their products.
WHO USES DEVOPS?
+--------------------------------------------------+
| |
| 🏢 TECH COMPANIES |
| Google, Amazon, Microsoft |
| |
| 🏦 BANKS |
| Mobile banking, online banking |
| |
| 🛍️ E-COMMERCE |
| Jumia, Konga, Shopify |
| |
| 🏛️ GOVERNMENT |
| Citizen services, digital ID |
| |
| 🏫 SCHOOLS |
| Learning platforms, student systems |
| |
| 🏥 HOSPITALS |
| Patient management, health records |
| |
| 🚀 STARTUPS |
| Building new products quickly |
| |
| ANYONE WHO BUILDS SOFTWARE! |
| |
+--------------------------------------------------+
DevOps is used by many different organizations. Tech companies, banks, e-commerce, government, schools, hospitals, and startups all use DevOps.
In this lesson, we will review everything we have learned about DevOps. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A Nigerian company has learned all these DevOps concepts. They work together, release software quickly, and keep their customers happy.
Your class has learned about DevOps. You understand how working together helps you build better projects.
Your family has learned about DevOps. You understand how planning together, giving feedback, and learning from mistakes helps your family work better.
A Nigerian entrepreneur has learned about DevOps. They are starting a new tech company and plan to use DevOps from the beginning.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 DevOps = Development + Operations |
| 📌 We need DevOps to build better software |
| 📌 DevOps started around 2009 |
| 📌 The DevOps Lifecycle has 8 stages |
| 📌 The Three Ways: Flow, Feedback, Learning |
| 📌 DevOps culture = working together |
| 📌 Agile + DevOps = Building + Running |
| 📌 Benefits: faster, fewer problems, happier |
| 📌 Everyone uses DevOps! |
| |
| YOU ARE NOW A DEVOPS BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about DevOps. It is a way of working where Developers and Operations work together. It helps teams build better software, faster.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| DevOps | A way of working where Developers and Operations work together to build software. |
| Development | The team that writes the code and builds new features. |
| Operations | The team that makes sure the software runs properly on servers. |
| Agile | A way of building software in short cycles, delivering small pieces frequently. |
| DevOps Lifecycle | The series of steps to build, test, release, and monitor software. |
| Flow | The First Way of DevOps — making work flow smoothly. |
| Feedback | The Second Way of DevOps — getting feedback quickly. |
| Continuous Learning | The Third Way of DevOps — always learning and improving. |
| Collaboration | Working together and sharing ideas. |
| Communication | Talking to each other openly and honestly. |
| Culture | The way people think and behave in a group. |
| Continuous Improvement | Always looking for ways to get better. |
Here are the most important concepts from this module. These are the big ideas that will help you understand DevOps.
DevOps brings people together. DevOps is not just about tools. It is about people working together. The most important part of DevOps is the culture of collaboration.
The DevOps Lifecycle is a roadmap. It has eight stages: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. Each stage has important tasks.
The Three Ways are the rules of DevOps. The First Way is about Flow. The Second Way is about Feedback. The Third Way is about Continuous Learning.
DevOps culture is key. A good culture includes collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
DevOps helps everyone. It helps Developers, Operations, the company, and the customers. It leads to faster releases, fewer problems, and happier people.
Let us look at how DevOps works in simple steps:
The team decides what to build. They talk about the features, the timeline, and the goals. They plan the work.
The Developers write the code. They build the features that were planned. They write clean, organized code.
The code is turned into a working program. This is called "building." The team makes sure the program runs.
The team tests the program to make sure it works. They look for bugs and fix them. They make sure the software is high quality.
The software is prepared to be used by customers. This includes making sure it is ready and all the paperwork is done.
The software is made available to users. It is put on the servers where customers can access it.
The team keeps the software running. They make sure it is available and working properly.
The team watches the software to find problems. They look for errors, slow performance, and other issues. Then they go back to Step 1 and do it all again!
STEP-BY-STEP: THE DEVOPS LIFECYCLE
Step 1: PLAN
+-------------------+
| Decide what to |
| build |
+-------------------+
|
V
Step 2: CODE
+-------------------+
| Write the code |
+-------------------+
|
V
Step 3: BUILD
+-------------------+
| Turn code into |
| a program |
+-------------------+
|
V
Step 4: TEST
+-------------------+
| Check it works |
+-------------------+
|
V
Step 5: RELEASE
+-------------------+
| Prepare for |
| users |
+-------------------+
|
V
Step 6: DEPLOY
+-------------------+
| Make available |
| to users |
+-------------------+
|
V
Step 7: OPERATE
+-------------------+
| Keep it running |
+-------------------+
|
V
Step 8: MONITOR
+-------------------+
| Watch for |
| problems |
+-------------------+
|
V
(Repeat from Step 1!)
A large technology company uses DevOps to build its search engine. The Developers and Operations teams work together. They release updates to the search engine every day. The search engine is always improving, and users are happy.
A bank uses DevOps to build its mobile app. The team releases new features every two weeks. The app is reliable and secure. Customers can do their banking from their phones without any problems.
A hospital uses DevOps to build a patient management system. The system helps doctors and nurses manage patient records. It is always available and works perfectly. Patients get better care.
Flutterwave is a Nigerian fintech company that uses DevOps to build its payment platform. The platform processes millions of transactions every day. The team uses DevOps to release new features quickly and keep the platform running smoothly.
Paystack is a Nigerian payment company (now part of Stripe). They use DevOps to build their payment infrastructure. They release updates frequently and their platform is very reliable.
Andela is a Nigerian company that builds software for clients all over the world. They use DevOps to collaborate with clients and deliver high-quality software quickly.
Your school is putting on a play. The actors (Developers) practice their lines. The stage crew (Operations) sets up the stage and lights. If they work together, the play is a success. If they do not talk, the play might be a disaster. DevOps is like the actors and stage crew working together!
You and your friends are working on a group project for school. Some of you research, some of you write, and some of you design. If you all work together and share ideas, the project is great. DevOps is like working together on a group project.
You are planning a birthday party. Some friends plan the games, some plan the food, and some plan the decorations. If you all work together, the party is amazing. DevOps is like planning a party together!
Your family is cooking dinner. The person chopping vegetables (Development) and the person cooking on the stove (Operations) work together. Dinner is ready on time and everyone enjoys it.
You and your friends are building a treehouse. The designer (Development) and the builder (Operations) work together. The treehouse is strong and fun.
Your family is planning a trip. The person planning activities (Development) and the person planning travel (Operations) work together. The trip is wonderful.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about DevOps and how it helps teams build software together. Here are some tips to support their learning:
Mistake 1: Thinking DevOps is only about tools.
DevOps is much more than just tools. It is about culture, process, and people working together. Tools are helpful, but they are not the most important part.
Mistake 2: Thinking DevOps is only for developers.
DevOps involves both Developers and Operations people. It is a team effort. Everyone works together.
Mistake 3: Thinking DevOps is easy.
DevOps takes effort and practice. It requires changing how people work and think. But it is worth it because of all the benefits.
Mistake 4: Blaming people when things go wrong.
In DevOps culture, we fix problems instead of blaming people. Blaming creates a bad culture. Fixing problems creates a good culture.
Mistake 5: Forgetting about continuous learning.
The Third Way is about always learning and improving. If you stop learning, you stop improving.
Mistake 6: Thinking DevOps is a one-time thing.
DevOps is a continuous process. You never "finish" DevOps. You keep improving and working together.
Start with culture, not tools.
Before you buy any tools, focus on building a good culture. Get people to work together and trust each other. Tools come later.
Start small.
You do not have to do everything at once. Start with one team or one project. Learn from that experience and then expand.
Automate everything.
In DevOps, we automate as much as possible. This includes building, testing, and deploying. Automation saves time and reduces mistakes.
Get feedback early and often.
Do not wait until the end to get feedback. Get feedback at every stage. This helps you catch problems early.
Learn from failures.
When something goes wrong, do not blame anyone. Instead, ask: "What did we learn?" and "How can we prevent this in the future?"
Keep improving.
Always look for ways to get better. There is always something you can improve.
THE DEVOPS LIFECYCLE
+--------------------------------------------------+
| |
| PLAN |
| (Decide what to build) |
| | |
| V |
| CODE |
| (Write the software) |
| | |
| V |
| BUILD |
| (Turn code into a program) |
| | |
| V |
| TEST |
| (Check it works) |
| | |
| V |
| RELEASE |
| (Prepare for users) |
| | |
| V |
| DEPLOY |
| (Make it available to users) |
| | |
| V |
| OPERATE |
| (Keep it running) |
| | |
| V |
| MONITOR |
| (Watch for problems) |
| | |
| V |
| (Go back to PLAN and repeat!) |
| |
+--------------------------------------------------+
THE THREE WAYS OF DEVOPS
+--------------------------------------------------+
| |
| THE FIRST WAY: FLOW |
| +------------------------------------+ |
| | Make work flow smoothly from | |
| | Development to Operations | |
| | "Keep the river flowing" | |
| +------------------------------------+ |
| | |
| V |
| THE SECOND WAY: FEEDBACK |
| +------------------------------------+ |
| | Get feedback quickly | |
| | "Taste the food while cooking" | |
| +------------------------------------+ |
| | |
| V |
| THE THIRD WAY: CONTINUOUS LEARNING |
| +------------------------------------+ |
| | Always learn and improve | |
| | "Get better every day" | |
| +------------------------------------+ |
| |
+--------------------------------------------------+
AGILE + DEVOPS
AGILE:
+--------------------------------------------------+
| Build software in short cycles (sprints) |
| Deliver small pieces frequently |
| Respond to change quickly |
| Focus on Development |
+--------------------------------------------------+
|
V
DEVOPS:
+--------------------------------------------------+
| Takes Agile and adds Operations |
| Development + Operations work together |
| Build AND run software |
| Continuous delivery and monitoring |
+--------------------------------------------------+
|
V
RESULT:
+--------------------------------------------------+
| Faster, better, more reliable software! |
| Happy developers, happy operations, happy users! |
+--------------------------------------------------+
| Aspect | Before DevOps | After DevOps |
|---|---|---|
| Collaboration | Teams worked separately | Teams work together |
| Releases | Slow (months or years) | Fast (days or weeks) |
| Problems | Many bugs and issues | Fewer problems |
| Culture | Blame culture | Blame-free culture |
| Learning | Learning was slow | Continuous learning |
| Customers | Unhappy customers | Happy customers |
| Aspect | Agile | DevOps |
|---|---|---|
| Focus | Building software | Building AND running software |
| Teams | Developers | Developers + Operations |
| Goal | Deliver working software | Deliver AND keep it running |
| Timeframe | Sprints (2-4 weeks) | Continuous delivery |
| Scope | Development only | Development + Operations |
| Way | What It Means | Simple Analogy |
|---|---|---|
| First Way (Flow) | Make work flow smoothly | A river flowing to the ocean |
| Second Way (Feedback) | Get feedback quickly | Tasting food while cooking |
| Third Way (Learning) | Always learn and improve | Getting better at a game |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 1 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
DevOps is a way of working where the people who build software (Developers) and the people who run the software (Operations) work together as one team. It helps teams build better software, faster.
We need DevOps because the old way of working separately caused problems like slow releases, many mistakes, finger-pointing, and unhappy customers. DevOps solves all these problems.
DevOps started around 2009 and has grown to be used by companies all over the world. It began with the Agile movement and evolved into a full way of working.
The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The eight stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
The Three Ways are the core principles of DevOps. The First Way is about Flow. The Second Way is about Feedback. The Third Way is about Continuous Learning.
DevOps culture is about working together, sharing ideas, and helping each other. Key elements include collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Agile is a way of building software in short cycles. DevOps extends Agile by bringing in the Operations team so that building and running software are done together.
DevOps leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
DevOps is used by tech companies, banks, e-commerce, government, schools, hospitals, and startups. Anyone who builds software can use DevOps.
You have now completed Module 1! You are ready to move on to Module 2, where you will learn about Version Control and Source Code Management. Keep up the great work!
Q1: What is DevOps?
A: DevOps is a way of working where Developers and Operations work together to build software. It helps teams build better software, faster.
Q2: Why is DevOps important?
A: DevOps is important because it solves the problems of the old way of working. It leads to faster releases, fewer problems, and happier customers.
Q3: Who uses DevOps?
A: DevOps is used by many different organizations. Tech companies, banks, e-commerce, government, schools, hospitals, and startups all use DevOps.
Q4: What are the Three Ways of DevOps?
A: The Three Ways are: Flow (making work flow smoothly), Feedback (getting feedback quickly), and Continuous Learning (always learning and improving).
Q5: What is the DevOps Lifecycle?
A: The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
Q6: What is the difference between Agile and DevOps?
A: Agile is about building software in short cycles. DevOps takes Agile and adds Operations so that building AND running software are done together.
Q7: What is DevOps culture?
A: DevOps culture is about working together, sharing ideas, and helping each other. It includes collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Q8: What are the benefits of DevOps?
A: DevOps leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
Q9: Do I need to be a developer to learn DevOps?
A: No! DevOps is for everyone. You can be a developer, an operations person, a manager, or anyone who works with software. DevOps is about people working together.
Q10: Is DevOps used in Nigeria?
A: Yes! Many Nigerian companies like Flutterwave, Paystack, and Andela use DevOps. It is helping Nigerian companies grow and compete globally.
What is DevOps?
Answer: DevOps is a way of working where Developers and Operations work together to build software.
Why do we need DevOps?
Answer: Because the old way of working separately caused problems like slow releases, many mistakes, and unhappy customers.
What does "DevOps" stand for?
Answer: DevOps combines "Development" and "Operations."
What are the eight stages of the DevOps Lifecycle?
Answer: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
What are the Three Ways of DevOps?
Answer: Flow, Feedback, and Continuous Learning.
What is the First Way of DevOps?
Answer: The First Way is Flow — making work flow smoothly from Development to Operations.
What is the Second Way of DevOps?
Answer: The Second Way is Feedback — getting feedback quickly so problems can be fixed early.
What is the Third Way of DevOps?
Answer: The Third Way is Continuous Learning — always learning and improving.
What is DevOps culture?
Answer: DevOps culture is about working together, sharing ideas, and helping each other.
Name three elements of DevOps culture.
Answer: Collaboration, communication, trust, being blame-free, continuous improvement, and shared goals. (Any three are acceptable.)
What is Agile?
Answer: Agile is a way of building software in short cycles, delivering small pieces frequently.
How is DevOps different from Agile?
Answer: Agile focuses on Development. DevOps takes Agile and adds Operations so that building AND running software are done together.
Name two benefits of DevOps.
Answer: Faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement. (Any two are acceptable.)
Who uses DevOps?
Answer: Tech companies, banks, e-commerce, government, schools, hospitals, and startups.
Can DevOps be used in Nigeria?
Answer: Yes! Many Nigerian companies like Flutterwave, Paystack, and Andela use DevOps.
Fill in the blanks with the correct words from the list:
Word list: DevOps, Development, Operations, Agile, Flow, Feedback, Continuous Learning, Lifecycle, Culture, Three Ways
__________ is a way of working where Developers and Operations work together.
Answer: DevOps
The __________ team writes the code and builds new features.
Answer: Development
The __________ team makes sure the software runs properly.
Answer: Operations
__________ is a way of building software in short cycles.
Answer: Agile
The First Way of DevOps is __________.
Answer: Flow
The Second Way of DevOps is __________.
Answer: Feedback
The Third Way of DevOps is __________.
Answer: Continuous Learning
The DevOps __________ has eight stages.
Answer: Lifecycle
DevOps __________ is about working together and sharing ideas.
Answer: Culture
The core principles of DevOps are called the __________.
Answer: Three Ways
Write True or False for each statement:
DevOps is only about tools.
Answer: False
DevOps brings Developers and Operations together.
Answer: True
The DevOps Lifecycle has 5 stages.
Answer: False (It has 8 stages)
The First Way of DevOps is Feedback.
Answer: False (The First Way is Flow)
DevOps culture is about working together.
Answer: True
Agile and DevOps are the same thing.
Answer: False
DevOps leads to faster releases.
Answer: True
In DevOps culture, we blame people when things go wrong.
Answer: False (We fix problems instead of blaming people)
DevOps is used by many different organizations.
Answer: True
The Third Way of DevOps is about continuous learning.
Answer: True
DevOps is not used in Nigeria.
Answer: False
The DevOps Lifecycle never stops.
Answer: True
DevOps is only for developers.
Answer: False
DevOps helps make customers happy.
Answer: True
DevOps is a one-time thing.
Answer: False
Choose the correct answer for each question:
What is DevOps?
A) A programming language
B) A way of working where Developers and Operations work together
C) A type of computer
D) A video game
Answer: B
What does "DevOps" combine?
A) Development and Operations
B) Design and Operations
C) Development and Design
D) Data and Operations
Answer: A
How many stages are in the DevOps Lifecycle?
A) 5
B) 6
C) 8
D) 10
Answer: C
Which is NOT a stage in the DevOps Lifecycle?
A) Plan
B) Code
C) Sing
D) Monitor
Answer: C
What is the First Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: B
What is the Second Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: A
What is the Third Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: C
Which is an element of DevOps culture?
A) Blaming people
B) Not communicating
C) Collaboration
D) Working alone
Answer: C
What is Agile?
A) A way of building software in short cycles
B) A way of running a marathon
C) A type of food
D) A video game
Answer: A
How is DevOps different from Agile?
A) DevOps is the same as Agile
B) DevOps adds Operations to Agile
C) DevOps is about design, not code
D) DevOps is older than Agile
Answer: B
Which is a benefit of DevOps?
A) Slower releases
B) More problems
C) Faster releases
D) Unhappy customers
Answer: C
Who uses DevOps?
A) Only tech companies
B) Only banks
C) Many different types of organizations
D) Only governments
Answer: C
Is DevOps used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
What is the most important part of DevOps?
A) Tools
B) People and culture
C) Computers
D) Money
Answer: B
What is the DevOps Lifecycle?
A) A series of steps to build, test, release, and monitor
software
B) A type of computer
C) A video game
D) A programming language
Answer: A
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. DevOps | A. The First Way — making work flow smoothly |
| 2. Development | B. The team that writes the code |
| 3. Operations | C. The team that runs the software |
| 4. Flow | D. A way of working where Developers and Operations work together |
| 5. Feedback | E. The Second Way — getting feedback quickly |
| 6. Continuous Learning | F. The Third Way — always learning and improving |
| 7. Agile | G. Building software in short cycles |
| 8. DevOps Lifecycle | H. The series of steps to build, test, release, and monitor software |
| 9. DevOps Culture | I. Working together, sharing ideas, and helping each other |
| 10. Three Ways | J. The core principles of DevOps |
Answers:
What is DevOps and why is it useful?
Answer: DevOps is a way of working where Developers and Operations work together to build software. It is useful because it leads to faster releases, fewer problems, and happier customers.
Explain the three stages of the DevOps Lifecycle.
Answer: The DevOps Lifecycle has eight stages: Plan (decide what to build), Code (write the software), Build (turn code into a program), Test (check it works), Release (prepare for users), Deploy (make it available), Operate (keep it running), and Monitor (watch for problems). Then it starts all over again.
What are the Three Ways of DevOps? Explain each one.
Answer: The Three Ways are:
What is DevOps culture and why is it important?
Answer: DevOps culture is about working together, sharing ideas, and helping each other. It is important because a good culture helps people work better together, which leads to better software and happier teams.
Give an example of how DevOps is used in Nigeria.
Answer: Flutterwave is a Nigerian fintech company that uses DevOps. They use DevOps to build their payment platform, which processes millions of transactions every day. They release new features quickly and keep the platform running smoothly.
A small tech startup in Lagos is building a new app. The Developers and Operations team do not talk to each other. The Developers build features quickly, but the Operations team cannot run them properly. The app keeps crashing, and customers are unhappy.
Question: How could DevOps help this startup?
Answer: DevOps could help by bringing the Developers and Operations team together. They would start talking, planning, and working together. The Developers would build features that the Operations team can run. The app would stop crashing, and customers would be happy.
A Nigerian bank wants to release new features for its mobile app more quickly. Currently, it takes 3 months to release any update. Customers are complaining about the lack of new features.
Question: How could DevOps help the bank release features faster?
Answer: DevOps could help the bank by making the flow of work smoother. The Developers and Operations teams would work together. They would build, test, and release features more quickly. Instead of taking 3 months, they could release updates in weeks or even days.
An e-commerce company in Nigeria has a website that goes down frequently during peak shopping times. Customers cannot place orders, and the company loses money.
Question: How could DevOps help prevent the website from crashing?
Answer: DevOps could help by improving collaboration between Developers and Operations. The Operations team would be involved from the start, helping the Developers build software that is more reliable. With DevOps, they would also monitor the website more closely and fix problems before they become big issues.
Instructions:
Instructions:
Why do you think teams often work separately instead of together?
Discuss with your classmates and share your ideas.
How would you feel if you were a Developer and the Operations team never talked to you?
Share your thoughts on why communication is important.
What are some other situations where people working together makes things better?
Think about different situations at home, at school, and in your community.
Do you think DevOps will become more or less important in the future? Why?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from using DevOps?
Share examples of companies in Nigeria.
What do you think is the most important principle of DevOps?
Explain why you think so.
Do you think DevOps would help your school? How?
Think about different projects and activities at school.
What is the most important thing you learned about DevOps today?
Share with the class.
Goal: Create a simple guide to teach beginners about DevOps.
Instructions:
Goal: Observe how DevOps principles apply in your community.
Instructions:
Scenario:
You are a DevOps consultant hired by a Nigerian company that sells products online. The company has a website that is slow, frequently crashes, and takes 6 months to release any new features. Customers are frustrated and going to competitors.
The company has:
Challenge: Create a complete DevOps plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 1: "Introduction to DevOps." You now understand what DevOps is, why it is important, and how it helps teams build better software.
In Module 2, you will learn:
Before you start Module 2, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 2! 🚀
© 2026 Certified DevOps Engineer Course • Module 1: Introduction to DevOps
Welcome to Module 2 of our Certified DevOps Engineer course! This module is called "Version Control & Source Code Management: Keeping Track of Your Work."
In this module, we will learn about a very important tool called Version Control. Version control helps teams keep track of all the changes they make to their code. It is like having a magic "undo" button for your entire project!
Think about writing a school essay. You write a draft, then you make changes, then you make more changes. Sometimes you realize you liked an older version better. Would not it be great if you could go back to any previous version of your essay? That is exactly what version control does for code!
Hello and welcome back! In Module 1, we learned about DevOps and why it is so important for building software. Now, in Module 2, we are going to learn about one of the most important tools in DevOps: Version Control.
Imagine you are building a giant LEGO castle. You build it step by step. Sometimes you make a mistake and need to take a part off. Sometimes you want to try a different design. What if you could save every version of your castle? What if you could go back to any previous version whenever you wanted? That is what version control does for software.
We will learn about a specific version control system called Git. Git is the most popular version control system in the world. It is used by millions of developers to keep track of their code. We will also learn about platforms like GitHub and GitLab where people store their Git repositories.
By the end of this module, you will understand how teams work together using Git, how to save different versions of your work, and how to collaborate with others without stepping on each other's toes.
So, are you ready? Let us dive in and discover the amazing world of version control!
By the time you finish this module, you will be able to:
Once upon a time, in a tech company in Lagos called "CodeVille," there was a team of developers building a new mobile app. The team was very talented, but they had one big problem: they did not use version control.
The team had a folder on their computers called "Final Code." But they kept changing it. So they made another folder called "Final Final Code." Then they made "Final Final Really Final Code." Then "Final Final Really Final For Real Code." It was a mess!
One day, a developer named Tunde made a big change to the code. But he made a mistake. The app stopped working. He tried to undo his change, but he could not remember what the old code looked like. The team spent three days trying to fix it, and they lost a big customer.
The team was very sad. They knew they needed a better way to work. That is when they discovered Git — a version control system that keeps track of every change to the code.
With Git, every change was saved. If someone made a mistake, they could easily go back to an older version. Team members could work on different parts of the code at the same time without messing up each other's work.
The team started using Git and GitHub. They never had a "code disaster" again. The app was released successfully, and CodeVille became one of the most successful tech companies in Nigeria.
This story shows us how important it is to keep track of changes. Version control helps teams avoid disasters and work together smoothly. Let us learn more about this amazing tool!
Version Control is a system that keeps track of all the changes you make to your files. It is like a time machine for your project!
Version control is important because it helps you remember what changes you made, when you made them, and why. It also helps teams work together without accidentally deleting each other's work.
Imagine you are writing a story. You write a page, save it, write another page, save it. Version control is like saving every version of your story as you go. But instead of just saving the latest version, it saves every single version you ever created. You can go back to any version anytime.
It is like having a magical notebook that never forgets anything you wrote, even if you erase it!
A team building a website uses version control. Every time someone fixes a bug or adds a new feature, it is saved. If something breaks, they can go back to the version that was working.
You are writing a report for school. You write a draft, your teacher gives feedback, you make changes. Version control would let you see every version of your report, from the first draft to the final version.
You are making a photo album. You add photos, rearrange them, and add captions. Version control would let you see every version of your album and go back to any previous version.
A Nigerian e-commerce company uses version control for their website. Every time they add a new product or change the design, it is saved. If a change causes a problem, they can easily undo it.
WHAT IS VERSION CONTROL?
+--------------------------------------------------+
| VERSION CONTROL |
| |
| Version 1.0 → Version 1.1 → Version 1.2 |
| | | | |
| V V V |
| +------+ +------+ +------+ |
| | Start| → | Add | → | Fix | |
| | File | | Line | | Bug | |
| +------+ +------+ +------+ |
| |
| You can go back to ANY previous version! |
| |
| Version 1.0 ← Version 1.1 ← Version 1.2 |
| (Go back!) |
| |
| Like a time machine for your work! 🕰️ |
| |
+--------------------------------------------------+
Version control is a system that keeps track of every change you make to your files. It is like a time machine that lets you go back to any previous version of your work.
Why we need version control: We need version control because it helps us keep track of changes, work together with others, and fix mistakes easily.
Without version control, teams can lose work, overwrite each other's changes, and waste time trying to fix mistakes. Version control makes everything organized and safe.
Imagine you and your friends are drawing a picture together on a big piece of paper. You each have a marker. If you all draw at the same time, you might draw over each other's work. It would be a mess!
Now imagine you have a rule: each person draws one part at a time, and you save a photo after each step. If someone makes a mistake, you can go back to the photo before the mistake. That is what version control does for code!
| Problem Without Version Control | Solution With Version Control |
|---|---|
| Lost work when files are deleted or overwritten | Every change is saved forever |
| Hard to remember what changes were made | Every change has a message describing it |
| Team members accidentally overwrite each other's work | Everyone works on their own copy and merges changes |
| Cannot go back to an older version | Can go back to ANY previous version instantly |
| No one knows who made what change | Every change has the author's name and date |
| Hard to try new ideas without breaking things | Can work on branches without affecting the main code |
A team of 10 developers works on a banking app. Without version control, they would constantly overwrite each other's code. With Git, they all work on their own copies and merge their changes together safely.
Your class is working on a big group project. Without version control, it is hard to keep track of who did what. With version control, everyone can see the history of the project and who contributed what.
Your family is planning a big event. Version control would help everyone see who added what to the plan and when. If someone makes a mistake, it can be undone easily.
A Nigerian fintech company has 50 developers working on their platform. They use version control to manage all the code. It helps them work together without chaos.
WHY WE NEED VERSION CONTROL
WITHOUT VERSION CONTROL:
+--------------------------------------------------+
| Developer 1: "I changed the code!" |
| Developer 2: "I also changed the code!" |
| Developer 3: "I changed the code too!" |
| |
| 🔥 CHAOS! Everything is overwritten! |
| Nobody knows who did what. |
| Code is broken. |
+--------------------------------------------------+
WITH VERSION CONTROL:
+--------------------------------------------------+
| Developer 1: Saves changes → Version 1.1 |
| Developer 2: Saves changes → Version 1.2 |
| Developer 3: Saves changes → Version 1.3 |
| |
| ✅ EVERYTHING IS ORGANIZED! |
| Everyone's changes are saved. |
| Can go back to any version. |
| Code is safe! |
+--------------------------------------------------+
We need version control because it helps us keep track of changes, work together, and fix mistakes easily. It prevents chaos and keeps everyone organized.
Git is a type of version control system. It is the most popular version control system in the world. It was created in 2005 by a man named Linus Torvalds (who also created Linux).
Git is important because it is used by millions of developers all over the world. If you want to work in technology, learning Git is essential.
Imagine Git as a special filing cabinet. Every time you make a change to your code, you put a new folder into the filing cabinet. Each folder has the date, who made the change, and a description of what was changed. You can open any folder anytime and see exactly what the code looked like at that time.
A company building a mobile app uses Git. Every developer has a full copy of the code on their laptop. They work on their own copy and share changes with each other using Git.
Your class is writing a school newspaper. Git would let each student work on their own copy of the articles. When they are done, they can combine all the articles together.
Your family is creating a family recipe book. Git would let everyone add and edit recipes on their own computers and then combine them.
A Nigerian developer at a company uses Git to manage code. Every developer has the full codebase on their computer. This is called a "distributed" system because everyone has their own copy.
WHAT IS GIT?
+--------------------------------------------------+
| GIT IS A VERSION CONTROL SYSTEM |
| |
| +------------------------------------------+ |
| | YOUR COMPUTER | |
| | +------------------------------------+ | |
| | | Full copy of the entire project | | |
| | | with all history | | |
| | +------------------------------------+ | |
| +------------------------------------------+ |
| |
| Git is like a filing cabinet where every |
| change is saved as a separate folder. |
| |
| +-------------+ +-------------+ +---------+ |
| | Version 1 | | Version 2 | | Version | |
| | (Start) | | (Add line) | | 3 (Fix) | |
| +-------------+ +-------------+ +---------+ |
| |
| 🔑 EVERYONE HAS THEIR OWN COPY |
| Git is "distributed" = everyone has everything! |
| |
+--------------------------------------------------+
Git is the most popular version control system in the world. It tracks every change to your code, and everyone has a full copy of the entire project.
A Git repository (or "repo" for short) is a folder on your computer where Git keeps track of all your files and their history. It is like the filing cabinet we talked about earlier.
The repository is where all the magic happens. Everything you do in Git happens inside a repository. Without a repository, Git cannot track anything.
Imagine you have a big box. This box is your "repository." Every time you make a change to your project, you put a new item into the box. The box also has a list of every item you have ever put in it. If you want to see an old version, you just look in the box.
| Type | What It Is | Example |
|---|---|---|
| Local Repository | The copy of the project on your own computer | The folder on your laptop |
| Remote Repository | A copy stored on a server (like GitHub or GitLab) | A repository on GitHub.com |
A developer has a Git repository on their laptop for a project. They also have a copy on GitHub. The one on the laptop is the "local" repo, and the one on GitHub is the "remote" repo.
Your class has a shared folder on the school network for projects. Each student has a copy on their computer (local), and there is a master copy on the school server (remote).
Your family has a shared photo album. You have a copy on your phone (local), and there is a copy on the cloud (remote).
A Nigerian startup has a Git repository on GitHub. Every developer has a copy on their laptop. They push their changes to the remote repository on GitHub so everyone can share.
GIT REPOSITORY
+--------------------------------------------------+
| |
| LOCAL REPOSITORY (On Your Computer) |
| +-------------------------------------------+ |
| | 📂 My Project | |
| | ├── index.html | |
| | ├── style.css | |
| | ├── script.js | |
| | └── .git ← Git tracking folder | |
| +-------------------------------------------+ |
| | |
| | Push (send changes) |
| V |
| REMOTE REPOSITORY (On GitHub/GitLab) |
| +-------------------------------------------+ |
| | 📂 My Project (on server) | |
| | ├── index.html | |
| | ├── style.css | |
| | ├── script.js | |
| | └── .git ← Git tracking folder | |
| +-------------------------------------------+ |
| | |
| | Pull (get changes) |
| V |
| LOCAL REPOSITORY (On Another Computer) |
| +-------------------------------------------+ |
| | 📂 My Project (friend's copy) | |
| | ├── index.html | |
| | ├── style.css | |
| | ├── script.js | |
| | └── .git ← Git tracking folder | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
A Git repository is a folder where Git tracks all your files and changes. There are local repositories (on your computer) and remote repositories (on a server like GitHub).
A commit is a snapshot of your files at a specific point in time. It is like taking a photo of your project. Each commit has a unique ID, a message, the author, and a date.
Commits are the heart of Git. They are how you save your work. Each commit is like a checkpoint that you can go back to anytime.
Imagine you are playing a video game. Every time you reach a new level, you save your game. If you make a mistake, you can go back to your last saved game. A commit is exactly like saving your game in Git!
Each save has a little note saying what you did. For example: "Added a new character" or "Fixed a bug."
A developer makes changes to a website. They do a Git commit with the message: "Added new homepage design." This saves a snapshot of the website with the new design.
You are writing a story. Every time you finish a chapter, you "commit" it with a message like "Finished Chapter 1." You can go back to any chapter anytime.
You are saving photos from a trip. Each day, you save the photos with a note like "Day 1: Beach." You can go back to any day's photos.
A developer in Abuja works on a fintech app. They commit their code every time they finish a new feature. The commit message says what the feature does.
GIT COMMIT
+--------------------------------------------------+
| COMMIT = SNAPSHOT OF YOUR WORK |
| |
| +--------------------------------------------+ |
| | COMMIT 1 | |
| | ID: abc123 | |
| | Message: "Started project" | |
| | Author: Tunde | |
| | Date: Monday, 10:00 AM | |
| | Files: index.html (new) | |
| +--------------------------------------------+ |
| | |
| V |
| +--------------------------------------------+ |
| | COMMIT 2 | |
| | ID: def456 | |
| | Message: "Added CSS styles" | |
| | Author: Tunde | |
| | Date: Monday, 11:30 AM | |
| | Files: style.css (new) | |
| +--------------------------------------------+ |
| | |
| V |
| +--------------------------------------------+ |
| | COMMIT 3 | |
| | ID: ghi789 | |
| | Message: "Fixed homepage bug" | |
| | Author: Ada | |
| | Date: Tuesday, 9:00 AM | |
| | Files: index.html (changed) | |
| +--------------------------------------------+ |
| |
| 🔑 Each commit is a saved checkpoint! |
| You can go back to ANY commit. |
| |
+--------------------------------------------------+
A commit is a snapshot of your project at a specific time. Each commit has a unique ID, a message, an author, and a date. It is like saving your game in a video game.
A branch is a separate line of development in Git. It allows you to work on new features or ideas without affecting the main code. It is like a separate path in a forest.
Branches are very important because they let you try new things safely. If your experiment does not work, you can just delete the branch and nothing happens to the main code. If it works, you can merge it into the main branch.
Imagine you are drawing a picture. The main drawing is on your paper. You want to try adding something new, but you are not sure if it will look good. Instead of drawing directly on the main picture, you use a tracing paper on top. You try your new idea on the tracing paper. If it looks good, you copy it to the main picture. If not, you just throw away the tracing paper.
In Git, the "tracing paper" is called a branch.
A team is building a shopping app. They have a "main" branch for the stable code. A developer creates a "feature/payment" branch to add a new payment system. They work on it, test it, and when it works, they merge it into "main."
Your class is writing a book. The main book is the "main" branch. Each student creates a "branch" to write their own chapter. When all chapters are done, they are merged into the main book.
Your family is planning a party. The main plan is the "main" branch. Each person creates a "branch" to plan a different part (food, games, decorations). When everything is planned, all the branches are merged into the main plan.
A Nigerian startup has a main branch for their production code. A developer creates a branch to add a new feature called "Mobile Money Integration." After testing, they merge it into the main branch.
GIT BRANCHING
+--------------------------------------------------+
| |
| main ────────────────────────────────────── |
| (Stable, production-ready code) |
| |
| feature/login |
| ────────────────────────────────────── |
| (Working on login feature) |
| |
| feature/payment |
| ────────────────────────────────── |
| (Working on payment feature) |
| |
| bugfix/header |
| ──────────────────────────── |
| (Fixing header bug) |
| |
| 🔑 Each branch is a separate line of work! |
| They can be merged back into main later. |
| |
+--------------------------------------------------+
A branch is a separate line of development. It lets you try new ideas safely without affecting the main code. Branches can be merged back into the main branch when they are ready.
Merging is the process of combining changes from one branch into another branch. It is how you bring your work back into the main branch.
Merging is how teams share their work. Without merging, everyone would have their own separate codebase. Merging brings everything together.
Imagine you and your friend are both working on the same puzzle. You are working on the left side, and your friend is working on the right side. When you both finish your parts, you put the puzzle together. That is exactly what merging is in Git!
Git is smart enough to combine the changes automatically. If both people changed the same line, Git asks you to decide which version to keep. This is called a "merge conflict," and it is easy to resolve.
| Type | What It Is |
|---|---|
| Fast-forward Merge | The branch is just ahead of main, so Git just moves the pointer |
| Three-way Merge | Both branches have changes, so Git combines them |
| Merge Conflict | Both branches changed the same lines, so Git asks you to decide |
A developer creates a branch to add a new feature. After finishing the feature, they merge the branch into "main." This brings the new feature into the main codebase.
Two students write different sections of a report. They merge their sections together to create the full report.
Two family members create different parts of a photo album. They merge their photos together to create the complete album.
A Nigerian company has several developers working on different features. They merge all their branches into the main branch every week. This is called a "merge day."
GIT MERGING
+--------------------------------------------------+
| BEFORE MERGING |
| |
| main ────────────────────────────────── |
| |
| feature/payment |
| ──────────────────────────────────── |
| (New payment code ready to be merged) |
| |
| ⬇️ MERGE! |
| |
| AFTER MERGING |
| |
| main ────────────────────────────────── |
| │ |
| V |
| feature/payment |
| ──────────────────────────────────── |
| (Now part of main!) |
| |
| 🔑 Merging combines changes from two branches! |
| The main branch now has the new payment code. |
| |
+--------------------------------------------------+
Merging is the process of combining changes from one branch into another. It is how teams share their work and bring everything together.
A Git workflow is a set of steps that developers follow when using Git. It is like a recipe that tells you what to do and when.
A workflow keeps everyone organized. When everyone follows the same steps, there is less confusion and fewer mistakes.
Imagine you are baking a cake. You follow a recipe: mix the ingredients, put it in the oven, let it cool, frost it. A Git workflow is just like a recipe for developers. It tells them the steps to follow when working with Git.
A developer follows this workflow every day. They clone the repo, create a branch, make changes, commit, push, and create a pull request. Then their changes are reviewed and merged.
Your class follows a workflow for projects: plan, research, write, edit, submit. A Git workflow is similar but for coding.
Your family follows a workflow for making dinner: plan the meal, buy ingredients, cook, serve, clean up. A Git workflow is like that but for software.
A Nigerian tech company follows a strict Git workflow. Every developer knows the steps. This keeps everything organized and helps them deliver software quickly.
BASIC GIT WORKFLOW
+--------------------------------------------------+
| |
| 1. CLONE |
| Copy repo to your computer |
| | |
| V |
| 2. BRANCH |
| Create a new branch for your work |
| | |
| V |
| 3. MAKE CHANGES |
| Edit and create files |
| | |
| V |
| 4. ADD |
| Tell Git which changes to save |
| | |
| V |
| 5. COMMIT |
| Save changes with a message |
| | |
| V |
| 6. PUSH |
| Send changes to remote repo |
| | |
| V |
| 7. PULL REQUEST |
| Ask to merge into main |
| | |
| V |
| 8. MERGE |
| Changes are merged into main! |
| |
| 🔑 Follow these steps to work with Git! |
| |
+--------------------------------------------------+
A Git workflow is a set of steps that developers follow. The basic steps are: clone, branch, make changes, add, commit, push, pull request, and merge.
GitHub and GitLab are websites where you can store your Git repositories online. They are like a home for your code on the internet.
GitHub and GitLab make it easy for teams to share code. They also have many features like issue tracking, project management, and code review.
Imagine you have a school project. You have a folder with all your work. GitHub and GitLab are like a shared folder on the school network. You can put your project there, and your classmates can access it too.
The difference is that GitHub and GitLab are on the internet, so you can access them from anywhere in the world!
| Feature | GitHub | GitLab |
|---|---|---|
| Founded | 2008 | 2014 |
| Owned By | Microsoft | GitLab Inc. |
| Free Features | Unlimited public repos, free private repos with limits | Very generous free tier |
| CI/CD | GitHub Actions | Built-in CI/CD |
| Popularity | Most popular | Popular, especially for private projects |
A company hosts their code on GitHub. All developers push their changes to GitHub. They use GitHub's pull request feature to review each other's code.
Your class has a project on GitHub. Everyone can see the code, suggest changes, and work together.
Your family creates a GitHub repository for a shared family website. Everyone can contribute photos and stories.
A Nigerian company uses GitLab for their projects. They like GitLab because it has built-in CI/CD. They host their code, run their tests, and deploy their app all from GitLab.
GITHUB AND GITLAB
+--------------------------------------------------+
| |
| GITHUB |
| +-------------------------------------------+ |
| | 🔑 Where code goes to live on the internet | |
| | ✅ Pull requests | |
| | ✅ Issue tracking | |
| | ✅ Project management | |
| | ✅ GitHub Actions (CI/CD) | |
| +-------------------------------------------+ |
| |
| GITLAB |
| +-------------------------------------------+ |
| | 🔑 All-in-one DevOps platform | |
| | ✅ Built-in CI/CD | |
| | ✅ Issue tracking | |
| | ✅ Project management | |
| | ✅ Self-hosted option | |
| +-------------------------------------------+ |
| |
| 🔑 Both are great for hosting Git repositories! |
| Choose the one that works best for you. |
| |
+--------------------------------------------------+
GitHub and GitLab are websites where you can store Git repositories online. They help teams share code, track issues, and manage projects.
Collaboration with Git is the process of multiple people working together on the same project using Git. Everyone has their own copy, and they share changes.
Collaboration is one of the main reasons we use Git. Git makes it easy for teams to work together without overwriting each other's work.
Imagine you and your friends are working on a giant puzzle. Instead of all working on the same piece at the same time, each person works on a different piece. When everyone is done, you put all the pieces together.
Git is like that. Each developer works on their own "piece" (branch). When they are done, they put all the "pieces" (branches) together using merge.
A team of 5 developers works on a project. Each developer creates branches for their features. They review each other's code through pull requests. Everyone works together smoothly.
A group of students works on a research project. Each student researches a different topic. They share their findings and combine them into one big report.
A family plans a reunion. Each person is responsible for a different part (food, location, activities). They share updates and combine their plans.
A Nigerian company has developers in Lagos, Abuja, and Port Harcourt. They use Git to collaborate even though they are in different cities. They all work on the same project using GitHub.
COLLABORATION WITH GIT
+--------------------------------------------------+
| TEAM WORKING TOGETHER |
| |
| Developer 1 (Lagos) Developer 2 (Abuja) |
| +------------------+ +------------------+ |
| | Branch: login | | Branch: payment | |
| | Work on login | | Work on payment | |
| | feature | | feature | |
| +------------------+ +------------------+ |
| | | |
| | Developer 3 (PH) | |
| | +------------------+ | |
| | | Branch: reports | | |
| | | Work on reports | | |
| | +------------------+ | |
| | | | |
| V V V |
| +------------------------------------------+ |
| | GITHUB (Remote Repo) | |
| | All branches are pushed and reviewed | |
| | ✅ Pull requests | |
| | ✅ Code review | |
| | ✅ Merge into main | |
| +------------------------------------------+ |
| |
| 🔑 Git makes remote collaboration easy! |
| |
+--------------------------------------------------+
Git makes it easy for teams to collaborate. Everyone works on their own branches, and changes are merged together through pull requests and code review.
A branching strategy is a plan for how a team uses branches in Git. It tells everyone when to create branches, what to name them, and how to merge them.
A branching strategy keeps everyone organized. Without a strategy, branches can become a mess. With a strategy, everything is clean and organized.
Imagine a library with no organization. Books are everywhere. You cannot find anything. Now imagine a library with a system: fiction books here, non-fiction there, children's books in another section. You can find everything easily. A branching strategy is like organizing the library.
| Strategy | What It Is | When to Use |
|---|---|---|
| Git Flow | Uses multiple types of branches: main, develop, feature, release, hotfix | Large projects with regular releases |
| GitHub Flow | Simple: just main and feature branches | Continuous deployment projects |
| Trunk-Based Development | Everyone works on main, short-lived feature branches | Very fast-paced projects |
A company uses GitHub Flow. They have a "main" branch and feature branches. Developers create feature branches for new features. When done, they merge into main through pull requests.
Your class uses a simple strategy for projects: the "master" copy is the main branch. Each student creates a branch for their part. When done, they merge into the master copy.
Your family uses a simple strategy for planning: the main plan is the "main" branch. Each person creates a branch for their part. When done, they merge into the main plan.
A Nigerian fintech uses Git Flow. They have "develop" for development, "main" for production, and feature branches for new features. This keeps their large project organized.
BRANCHING STRATEGIES
GIT FLOW:
+--------------------------------------------------+
| |
| main ──────────────────────────────────── |
| │ |
| V |
| develop ────────────────────────────────────── |
| │ |
| V |
| feature/login ────────────────────────────── |
| feature/payment ──────────────────────────── |
| release/1.0 ────────────────────────────────── |
| hotfix/urgent ────────────────────────────── |
| |
| GITHUB FLOW: |
| main ──────────────────────────────────── |
| │ |
| V |
| feature/login ────────────────────────────── |
| feature/payment ──────────────────────────── |
| |
| 🔑 Choose a strategy that fits your team! |
| |
+--------------------------------------------------+
A branching strategy is a plan for using branches. Common strategies include Git Flow, GitHub Flow, and Trunk-Based Development. Choose one that works for your team.
In this lesson, we will review everything we have learned about version control and Git. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use Git every day. They create branches, commit changes, and merge pull requests. Their project is organized and successful.
Your class has learned about Git. They understand how to keep track of changes and work together on projects.
Your family has learned about version control. They understand the importance of keeping track of changes and working together.
A Nigerian developer has learned all these Git concepts. They can now work effectively with their team and contribute to their company's success.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 Version Control = Track changes |
| 📌 Git = Popular version control system |
| 📌 Repository = Where Git tracks files |
| 📌 Commit = Snapshot of your project |
| 📌 Branch = Separate line of development |
| 📌 Merge = Combine changes from branches |
| 📌 Workflow = Steps to follow |
| 📌 GitHub/GitLab = Host Git repos |
| 📌 Collaboration = Work together using Git |
| 📌 Branching Strategy = Plan for using branches |
| |
| YOU ARE NOW A GIT BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about version control and Git. Git helps teams track changes, work together, and build better software.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Version Control | A system that tracks changes to files, like a time machine |
| Git | The most popular version control system in the world |
| Repository (Repo) | A folder where Git tracks all your files and changes |
| Commit | A snapshot of your project at a specific time |
| Branch | A separate line of development in Git |
| Merge | Combining changes from one branch into another |
| Clone | Copying a repository to your computer |
| Push | Sending your changes to the remote repository |
| Pull | Getting the latest changes from the remote repository |
| GitHub | A website for hosting Git repositories (owned by Microsoft) |
| GitLab | A website for hosting Git repositories with built-in CI/CD |
| Pull Request | A request to merge your changes into the main branch |
| Merge Conflict | When two branches have changes to the same lines |
| Branching Strategy | A plan for how a team uses branches |
| Collaboration | Working together on the same project |
Here are the most important concepts from this module. These are the big ideas that will help you understand version control.
Version control keeps track of every change. It is like a time machine for your project. You can go back to any version of your work anytime.
Git is the most popular version control system. It is distributed, meaning everyone has a full copy of the project on their computer.
Commits are snapshots of your project. Each commit has a message, author, date, and unique ID. They are like save points in a video game.
Branches let you work on new ideas safely. You can create a branch, try something new, and if it does not work, delete the branch without affecting the main code.
Merging combines changes from different branches. This is how teams share their work and bring everything together.
GitHub and GitLab host Git repositories online. They help teams collaborate, review code, and manage projects.
Git makes collaboration easy. Everyone works on their own copy and shares changes through push, pull, and pull requests.
Let us look at how to use Git in simple steps:
You start by making a copy of the project on your computer. This is called "cloning." You use the command: git clone followed by the repository URL.
Before you make changes, create a new branch. This keeps your work separate from the main code. Use: git branch feature/name and then git checkout feature/name to switch to it.
Edit the code, add new files, and make any changes you need. This is where you do your work.
Tell Git which changes you want to save. Use: git add . to add all changes, or git add filename to add specific files.
Save your changes with a message. Use: git commit -m "Your message". The message should describe what you changed.
Send your branch to the remote repository (like GitHub). Use: git push origin feature/name.
On GitHub or GitLab, create a pull request. This tells your team that you are ready to merge your changes into the main branch.
Your team reviews your code. They might ask for changes. When everything is good, they merge your pull request into the main branch.
STEP-BY-STEP: USING GIT
Step 1: CLONE
+-------------------+
| git clone URL |
+-------------------+
|
V
Step 2: BRANCH
+-------------------+
| git branch feature|
| git checkout feat |
+-------------------+
|
V
Step 3: MAKE CHANGES
+-------------------+
| Edit code |
| Add new files |
+-------------------+
|
V
Step 4: ADD
+-------------------+
| git add . |
+-------------------+
|
V
Step 5: COMMIT
+-------------------+
| git commit -m |
| "Message" |
+-------------------+
|
V
Step 6: PUSH
+-------------------+
| git push origin |
| feature |
+-------------------+
|
V
Step 7: PULL REQUEST
+-------------------+
| Create PR on |
| GitHub/GitLab |
+-------------------+
|
V
Step 8: MERGE
+-------------------+
| Review and merge |
| into main |
+-------------------+
An e-commerce company uses Git to manage their website code. They have a "main" branch for the live website. When developers want to add new features, they create branches. After testing, they merge into main through pull requests.
A mobile app development team uses Git. Each developer works on different features. They use GitHub for hosting. They review each other's code through pull requests before merging.
An open source project on GitHub has contributors from all over the world. They use Git to collaborate. Anyone can contribute by creating a branch, making changes, and submitting a pull request.
Flutterwave, a Nigerian fintech company, uses Git and GitHub. They have developers in multiple cities. Git helps them work together and track changes to their payment platform.
Paystack uses Git for their code. They have a strict workflow with branches and pull requests. This helps them maintain high quality code.
Many Nigerian developers use GitHub to share their projects. They contribute to open source projects and build their portfolios. Git helps them showcase their skills to employers.
Your class is writing a book together. Each student writes a chapter. Git would be like a folder where all the chapters are saved. You can see who wrote what chapter and when.
You are playing a video game with save points. Every time you save, you can go back to that point if you make a mistake. Git commits are exactly like save points in a game!
You are drawing a picture with your friends. Each friend draws on their own paper. When you are done, you put all the papers together to make one big picture. Git branches are like each friend's paper, and merging is like putting them together.
Your family has a recipe book. Every time someone adds a new recipe or changes an old one, it is saved. You can always see the original recipe and any changes made. That is like version control!
Your family has a photo album. You add photos, remove photos, and rearrange them. You can always go back to the original version. That is like version control.
You have a folder for your homework. Every time you make changes to your homework, you save it. You can always go back to an older version. That is like version control.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about version control and Git. Here are some tips to support their learning:
Mistake 1: Not committing often enough.
Some people make many changes and then do one big commit. This makes it hard to know what changed. It is better to commit frequently with clear messages.
Mistake 2: Writing bad commit messages.
A commit message like "fixed stuff" is not helpful. Write clear messages like "Fixed the login button bug" or "Added payment feature."
Mistake 3: Working directly on the main branch.
You should always create a branch for your work. Working directly on main can break the code for everyone.
Mistake 4: Forgetting to pull before pushing.
Always pull the latest changes before pushing your own. This helps avoid merge conflicts.
Mistake 5: Not reviewing code before merging.
Always have someone review your code before merging. This helps catch mistakes and improve quality.
Mistake 6: Ignoring merge conflicts.
Merge conflicts happen when two people change the same lines. Do not ignore them. Resolve them carefully.
Commit frequently.
Make small, frequent commits with clear messages. This makes it easier to understand the history and revert changes if needed.
Write good commit messages.
A good commit message describes what was changed and why. Example: "Fixed bug where login button did not work on mobile."
Always branch for new work.
Never work directly on the main branch. Always create a branch for your changes.
Pull before you push.
Before pushing your changes, pull the latest changes from the remote repository. This avoids merge conflicts.
Review code before merging.
Always have at least one person review your code before you merge it. This improves quality and catches mistakes.
Resolve merge conflicts carefully.
When you have a merge conflict, take time to resolve it carefully. Make sure you keep the correct changes.
GIT BASICS
+--------------------------------------------------+
| |
| REPOSITORY (Repo) |
| +-------------------------------------------+ |
| | 📂 My Project | |
| | ├── index.html | |
| | ├── style.css | |
| | └── .git (Git tracking folder) | |
| +-------------------------------------------+ |
| |
| COMMIT = Snapshot |
| +------------+ +------------+ +------------+ |
| | Commit 1 | | Commit 2 | | Commit 3 | |
| | "Start" | | "Add CSS" | | "Fix bug" | |
| +------------+ +------------+ +------------+ |
| |
| BRANCH = Separate Line of Work |
| main ──────────────────────────────────── |
| │ |
| V |
| feature/login ──────────────────────────── |
| |
| MERGE = Combine Branches |
| main ──────────────────────────────────── |
| │ |
| V |
| feature/login ──────────────────────────── |
| (Merged into main!) |
| |
+--------------------------------------------------+
GIT WORKFLOW
+--------------------------------------------------+
| |
| 1. CLONE |
| git clone URL |
| | |
| V |
| 2. BRANCH |
| git checkout -b feature/name |
| | |
| V |
| 3. MAKE CHANGES |
| Edit files |
| Add new files |
| | |
| V |
| 4. ADD |
| git add . |
| | |
| V |
| 5. COMMIT |
| git commit -m "Description" |
| | |
| V |
| 6. PUSH |
| git push origin feature/name |
| | |
| V |
| 7. PULL REQUEST |
| Create PR on GitHub/GitLab |
| | |
| V |
| 8. MERGE |
| Review and merge into main |
| |
+--------------------------------------------------+
BRANCHING STRATEGIES
GIT FLOW:
+--------------------------------------------------+
| |
| main ──────────────────────────────────── |
| │ |
| V |
| develop ────────────────────────────────────── |
| │ |
| V |
| feature/login ────────────────────────────── |
| feature/payment ──────────────────────────── |
| release/1.0 ────────────────────────────────── |
| hotfix/urgent ────────────────────────────── |
| |
+--------------------------------------------------+
GITHUB FLOW:
+--------------------------------------------------+
| |
| main ──────────────────────────────────── |
| │ |
| V |
| feature/login ────────────────────────────── |
| feature/payment ──────────────────────────── |
| |
+--------------------------------------------------+
| Feature | Git | SVN | Mercurial |
|---|---|---|---|
| Type | Distributed | Centralized | Distributed |
| Speed | Very fast | Slower | Fast |
| Branching | Very easy | Harder | Easy |
| Popularity | Most popular | Declining | Less popular |
| Offline Work | Yes | Limited | Yes |
| Platforms | GitHub, GitLab, Bitbucket | Apache, AWS | Bitbucket, Heptapod |
| Feature | GitHub | GitLab |
|---|---|---|
| Founded | 2008 | 2014 |
| Owned By | Microsoft | GitLab Inc. |
| Free Tier | Unlimited public repos, free private with limits | Very generous free tier |
| Built-in CI/CD | GitHub Actions | Yes, built-in |
| Self-Hosted | GitHub Enterprise (paid) | Yes, free (CE) and paid (EE) |
| Most Popular For | Open source, public projects | Private projects, all-in-one DevOps |
| Strategy | Complexity | Best For | Key Branches |
|---|---|---|---|
| Git Flow | High | Large projects with regular releases | main, develop, feature, release, hotfix |
| GitHub Flow | Low | Continuous deployment projects | main, feature |
| Trunk-Based | Low | Very fast-paced projects | main, short-lived feature |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 2 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Version control is a system that keeps track of changes to your files. It is like a time machine for your project. You can go back to any previous version anytime.
Git is the most popular version control system in the world. It is distributed, meaning everyone has a full copy of the project on their computer. Git was created in 2005 by Linus Torvalds.
We learned about repositories (folders where Git tracks files), commits (snapshots of your project), branches (separate lines of development), and merging (combining changes from different branches).
The basic Git workflow is: clone, branch, make changes, add, commit, push, pull request, and merge. Following this workflow keeps everything organized.
GitHub and GitLab are websites for hosting Git repositories. They help teams collaborate, review code, and manage projects. GitHub is owned by Microsoft, and GitLab is an independent company.
Git makes it easy for teams to collaborate. Branching strategies like Git Flow, GitHub Flow, and Trunk-Based Development help keep branches organized.
You have now completed Module 2! You are ready to move on to Module 3, where you will learn about Continuous Integration (CI). Keep up the great work!
Q1: What is version control?
A: Version control is a system that keeps track of all the changes you make to your files. It is like a time machine for your project.
Q2: What is Git?
A: Git is the most popular version control system in the world. It was created in 2005 by Linus Torvalds.
Q3: What is a repository (repo)?
A: A repository is a folder where Git tracks all your files and their history. It is like a filing cabinet for your project.
Q4: What is a commit?
A: A commit is a snapshot of your project at a specific time. It has a message, author, date, and unique ID.
Q5: What is a branch?
A: A branch is a separate line of development in Git. It lets you try new ideas without affecting the main code.
Q6: What is merging?
A: Merging is the process of combining changes from one branch into another. It is how teams share their work.
Q7: What is the difference between GitHub and GitLab?
A: Both are websites for hosting Git repositories. GitHub is owned by Microsoft and is most popular for open source. GitLab has built-in CI/CD and can be self-hosted.
Q8: What is a pull request?
A: A pull request is a request to merge your changes into the main branch. It allows team members to review your code before it is merged.
Q9: What is a branching strategy?
A: A branching strategy is a plan for how a team uses branches in Git. Examples include Git Flow, GitHub Flow, and Trunk-Based Development.
Q10: Is Git used in Nigeria?
A: Yes! Many Nigerian developers and companies use Git and GitHub. It is an essential skill for software development in Nigeria.
What is version control?
Answer: Version control is a system that keeps track of changes to files, like a time machine.
What is Git?
Answer: Git is the most popular version control system in the world.
What is a repository?
Answer: A repository is a folder where Git tracks all your files and changes.
What is a commit?
Answer: A commit is a snapshot of your project at a specific time.
What is a branch?
Answer: A branch is a separate line of development in Git.
What is merging?
Answer: Merging is combining changes from one branch into another.
What does "git add" do?
Answer: It tells Git which changes you want to save in the next commit.
What does "git commit" do?
Answer: It saves your changes with a message.
What does "git push" do?
Answer: It sends your changes to the remote repository.
What does "git pull" do?
Answer: It gets the latest changes from the remote repository.
What is a pull request?
Answer: A pull request is a request to merge your changes into the main branch.
What is the difference between GitHub and GitLab?
Answer: Both host Git repositories. GitHub is owned by Microsoft and is popular for open source. GitLab has built-in CI/CD and can be self-hosted.
What is a branching strategy?
Answer: A branching strategy is a plan for how a team uses branches in Git.
Name one branching strategy.
Answer: Git Flow, GitHub Flow, or Trunk-Based Development.
Is Git used in Nigeria?
Answer: Yes, many Nigerian developers and companies use Git.
Fill in the blanks with the correct words from the list:
Word list: version control, Git, repository, commit, branch, merge, clone, push, pull, GitHub, GitLab, pull request
__________ is a system that tracks changes to your files.
Answer: version control
__________ is the most popular version control system.
Answer: Git
A __________ is a folder where Git tracks all your files.
Answer: repository
A __________ is a snapshot of your project at a specific time.
Answer: commit
A __________ is a separate line of development in Git.
Answer: branch
__________ is the process of combining changes from one branch into another.
Answer: merge
To copy a repository to your computer, you use the command __________.
Answer: clone
To send your changes to the remote repository, you use the command __________.
Answer: push
To get the latest changes from the remote repository, you use the command __________.
Answer: pull
A __________ is a request to merge your changes into the main branch.
Answer: pull request
__________ is a website for hosting Git repositories owned by Microsoft.
Answer: GitHub
__________ is a website for hosting Git repositories with built-in CI/CD.
Answer: GitLab
Write True or False for each statement:
Version control is like a time machine for your project.
Answer: True
Git was created in 2020.
Answer: False (It was created in 2005)
A repository is where Git tracks your files.
Answer: True
A commit is a snapshot of your project.
Answer: True
A branch is the main line of development in Git.
Answer: False (A branch is a separate line of development)
Merging combines changes from different branches.
Answer: True
"git add" saves your changes with a message.
Answer: False (git commit saves changes with a message; git add stages changes)
"git push" sends changes to the remote repository.
Answer: True
"git pull" gets the latest changes from the remote repository.
Answer: True
GitHub is owned by Google.
Answer: False (GitHub is owned by Microsoft)
GitLab has built-in CI/CD.
Answer: True
A pull request is a request to merge changes into the main branch.
Answer: True
Git is not used in Nigeria.
Answer: False
You should work directly on the main branch.
Answer: False (You should create branches for your work)
Git is a distributed version control system.
Answer: True
Choose the correct answer for each question:
What is version control?
A) A type of computer
B) A system that tracks changes to files
C) A programming language
D) A video game
Answer: B
When was Git created?
A) 1995
B) 2000
C) 2005
D) 2010
Answer: C
What is a repository?
A) A type of branch
B) A folder where Git tracks files
C) A commit message
D) A pull request
Answer: B
What is a commit?
A) A separate line of development
B) A snapshot of your project at a specific time
C) A combination of branches
D) A hosting platform
Answer: B
What is a branch?
A) A separate line of development
B) A snapshot of your project
C) A hosting platform
D) A commit message
Answer: A
What is merging?
A) Creating a new branch
B) Combining changes from one branch into another
C) Deleting a branch
D) Copying a repository
Answer: B
What does "git clone" do?
A) Saves changes
B) Copies a repository to your computer
C) Sends changes to remote
D) Gets changes from remote
Answer: B
What does "git push" do?
A) Copies a repository
B) Saves changes
C) Sends changes to remote
D) Gets changes from remote
Answer: C
What does "git pull" do?
A) Copies a repository
B) Saves changes
C) Sends changes to remote
D) Gets changes from remote
Answer: D
What is a pull request?
A) A type of branch
B) A request to merge changes into the main branch
C) A commit message
D) A hosting platform
Answer: B
Which company owns GitHub?
A) Google
B) Amazon
C) Microsoft
D) Apple
Answer: C
Which platform has built-in CI/CD?
A) GitHub only
B) GitLab only
C) Both GitHub and GitLab
D) Neither
Answer: B (GitLab has built-in CI/CD; GitHub has GitHub Actions)
What is a branching strategy?
A) A plan for using branches in Git
B) A type of commit
C) A hosting platform
D) A version control system
Answer: A
Which is a branching strategy?
A) Git Flow
B) Git Push
C) Git Commit
D) Git Clone
Answer: A
Is Git used in Nigeria?
A) No
B) Yes, by many developers
C) Only in Lagos
D) Only by the government
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Version Control | A. A snapshot of your project at a specific time |
| 2. Git | B. A separate line of development |
| 3. Repository | C. A system that tracks changes to files |
| 4. Commit | D. The most popular version control system |
| 5. Branch | E. Combining changes from one branch into another |
| 6. Merge | F. A folder where Git tracks files |
| 7. Clone | G. Copying a repository to your computer |
| 8. Push | H. Getting the latest changes from remote |
| 9. Pull | I. Sending changes to the remote repository |
| 10. Pull Request | J. A request to merge changes into the main branch |
Answers:
What is version control and why is it useful?
Answer: Version control is a system that keeps track of changes to your files. It is useful because it lets you see who changed what, when, and why. You can also go back to any previous version of your work.
Explain the difference between a branch and a merge.
Answer: A branch is a separate line of development where you can work on new ideas without affecting the main code. Merging is the process of combining changes from one branch into another.
Describe the basic Git workflow.
Answer: The basic Git workflow is:
What is the difference between GitHub and GitLab?
Answer: Both are websites for hosting Git repositories. GitHub is owned by Microsoft and is very popular for open source projects. GitLab is an independent company and has built-in CI/CD. GitLab can also be self-hosted.
Why is Git important for DevOps?
Answer: Git is important for DevOps because it is how teams manage code changes. It helps teams collaborate, track changes, and maintain different versions of the code. Without Git, DevOps would be very difficult.
A team of developers is working on a project. They do not use version control. They share code via email. Sometimes they overwrite each other's work. They often lose changes. They spend a lot of time trying to fix problems.
Question: How could Git help this team?
Answer: Git could help by providing a central place to store code (a repository). Every change would be tracked. Developers would work on their own branches and merge changes through pull requests. They would never lose work again and could easily go back to older versions if needed.
A developer wants to add a new feature to an app. They are worried about breaking the existing code. They want to try the feature but need to make sure it works before sharing it.
Question: How can the developer use Git to safely try the new feature?
Answer: The developer can create a new branch for the feature (git branch feature/new-feature). They can work on the feature on this branch without affecting the main code. When the feature is ready, they can create a pull request. The team can review it, and when it works, they can merge it into the main branch.
A Nigerian startup has 3 developers working on a mobile app. They want to work together efficiently. They need to keep track of changes and avoid overwriting each other's work.
Question: What should the startup use to manage their code?
Answer: The startup should use Git with a hosting platform like GitHub or GitLab. They would create a repository, each developer would clone it, and they would follow a Git workflow with branches and pull requests. This would keep their code organized and help them work together smoothly.
Instructions:
Instructions:
Why do you think keeping track of changes is important?
Discuss with your classmates and share your ideas.
Have you ever lost work because you did not save it? How would version control help?
Share your experiences and thoughts.
What are some other situations where it is important to keep track of different versions?
Think about school, home, and other activities.
Why do you think GitHub is so popular?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from using Git?
Share examples of companies in Nigeria.
What do you think is the most important Git command for beginners?
Explain why you think so.
Do you think Git is easy to learn? Why or why not?
Share your thoughts.
What is the most important thing you learned about Git today?
Share with the class.
Goal: Create a simple guide to teach beginners about Git.
Instructions:
Goal: Practice using Git commands.
Instructions:
Scenario:
You are a Git expert at a Nigerian tech company. The company has 10 developers working on a large project. They are new to Git and need your help setting up a good workflow.
The company has:
Challenge: Create a complete Git workflow plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's development team.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 2: "Version Control & Source Code Management." You now understand how Git helps teams keep track of changes and collaborate on code.
In Module 3, you will learn:
Before you start Module 3, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 3! 🚀
© 2026 Certified DevOps Engineer Course • Module 2: Version Control & Source Code Management
Welcome to Module 3 of our Certified DevOps Engineer course! This module is called "Continuous Integration (CI): Building and Testing Code Automatically."
In this module, we will learn about Continuous Integration, which is a very important part of DevOps. CI is all about automatically building and testing code every time a developer makes a change. It helps teams catch mistakes early and make sure the code is always working.
Think of CI like having a robot helper that checks your homework every time you make a change. The robot makes sure everything is correct and tells you if there are any problems. This way, you can fix mistakes immediately before they become big problems.
Hello and welcome back! In Module 1, we learned about DevOps and why it is important. In Module 2, we learned about Git and how teams track changes to their code. Now, in Module 3, we are going to learn about Continuous Integration (CI).
Imagine you are building a very tall tower with blocks. Every time you add a new block, you need to make sure the tower is still stable. You check to see if the blocks are balanced and the tower is not going to fall over. CI is exactly like that for code!
Every time a developer adds new code (like adding a new block to the tower), CI automatically checks to see if everything still works. It builds the code and runs tests to make sure nothing is broken. If something is wrong, the developer is told immediately so they can fix it.
In this module, we will learn all about CI — what it is, why it is important, how it works, and what tools we use to do it. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover the amazing world of Continuous Integration!
By the time you finish this module, you will be able to:
Once upon a time, in a busy tech company in Nigeria called "BuildIt Solutions," there was a team of developers building a mobile app. The team was very talented, but they had a big problem.
Every day, the developers would write new code and add it to the main codebase. But they would only test their code on their own computers. They did not have a system to test everything together.
One day, a developer named Ada added some new code. It worked perfectly on her computer. But when she shared it with the team, it broke everything. The app would not start. Other developers could not work. The team spent two whole days trying to find and fix the problem.
The team was very frustrated. They knew they needed a way to catch problems before they broke everything. That is when they discovered Continuous Integration (CI).
With CI, every time a developer added new code, a special system would automatically build the code and run tests. If something was wrong, the developer would be told immediately. Problems were caught early, before they could break everything.
The team set up CI for their project. Now, every time Ada or any other developer added code, the CI system would check it. If something broke, they fixed it right away. The app never broke again, and the team became one of the most productive in Nigeria.
This story shows us how important it is to catch problems early. CI helps teams do exactly that. Let us learn more about this amazing tool!
Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change. "Continuous" means "all the time," and "Integration" means "putting things together."
CI is important because it catches problems early. Instead of finding bugs weeks later, CI finds them immediately. This saves time, money, and frustration.
Imagine you are building a puzzle. Every time you add a new piece, you check to make sure it fits perfectly. If it does not fit, you fix it before adding more pieces. CI is like that for code!
Every time a developer adds new code, CI automatically checks to see if everything still works. It builds the code and runs tests. If something is wrong, the developer is told immediately.
A company building a banking app uses CI. Every time a developer changes the code, CI runs thousands of tests automatically. If any test fails, the developer fixes it before the code is shared with the rest of the team.
Your teacher gives you a big project to work on. Every time you finish a section, you show it to your teacher to make sure you are on the right track. CI is like showing your work to the teacher regularly.
You are cooking a meal. Every time you add a new ingredient, you taste it to make sure it is good. If it is not, you can fix it before the meal is finished. CI is like tasting your food while cooking.
A Nigerian fintech company uses CI to test their payment system. Every time a developer adds code, the CI system runs thousands of tests to make sure the payment system works perfectly. This prevents problems that could affect customers.
WHAT IS CONTINUOUS INTEGRATION?
+--------------------------------------------------+
| |
| DEVELOPER MAKES A CHANGE |
| +-------------------------------------------+ |
| | Developer adds new code | |
| | Developer pushes code to repository | |
| +-------------------------------------------+ |
| | |
| V |
| CI SYSTEM RUNS AUTOMATICALLY |
| +-------------------------------------------+ |
| | 1. Build the code | |
| | 2. Run tests | |
| | 3. Check for problems | |
| +-------------------------------------------+ |
| | |
| V |
| RESULTS |
| +-------------------------------------------+ |
| | ✅ All tests pass = Code is good! | |
| | ❌ Tests fail = Fix the problem! | |
| +-------------------------------------------+ |
| |
| 🔑 CI = Automatic building and testing of code! |
| |
+--------------------------------------------------+
Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change. It catches problems early and saves time.
Why we need CI: We need CI because without it, problems can hide in the code for a long time. When problems are found late, they are much harder and more expensive to fix.
CI helps teams deliver better software faster. It reduces bugs, improves team productivity, and makes everyone happier.
Imagine you are building a house. If you find a problem with the foundation after you have built the whole house, it is very hard to fix. But if you check the foundation while you are building it, you can fix problems easily. CI is like checking the foundation regularly.
| Problem | What It Means | CI Solution |
|---|---|---|
| Late Bug Discovery | Bugs are found weeks after they were introduced | CI finds bugs immediately |
| Hard to Fix | Bugs are harder to fix when found late | Bugs are easy to fix when found early |
| Slow Releases | Releases are delayed because of bugs | Releases are faster with fewer bugs |
| Developer Frustration | Developers are frustrated fixing other people's bugs | Developers fix their own bugs quickly |
| Unhappy Customers | Customers get buggy software | Customers get reliable software |
A company without CI once found a critical bug just before a big release. They had to delay the release by two weeks to fix it. After adopting CI, they caught bugs immediately and released on time.
Your class is working on a group project. Without regular check-ins, problems are found only at the end. With regular check-ins (like CI), problems are found and fixed early.
Your family is planning a party. If you wait until the last day to check everything, you might find problems. If you check regularly (like CI), you can fix problems early.
A Nigerian e-commerce company used to have many bugs in their website. Customers would complain about items not adding to cart. After adopting CI, they caught bugs early and fixed them. Customer complaints dropped by 80%.
WHY WE NEED CI
WITHOUT CI:
+--------------------------------------------------+
| Developer adds code → Code sits for weeks |
| → Code is tested → Bug found → Hard to fix |
| → Release delayed → Customers unhappy |
| |
| 😞 Lots of problems, slow releases |
+--------------------------------------------------+
WITH CI:
+--------------------------------------------------+
| Developer adds code → CI tests immediately |
| → Bug found → Easy to fix → Code is good |
| → Release on time → Customers happy |
| |
| 😊 Fewer problems, faster releases |
+--------------------------------------------------+
We need CI because it catches problems early. Without CI, bugs hide in the code and become harder and more expensive to fix. CI helps teams deliver better software faster.
A CI pipeline is the series of steps that CI follows to build and test the code. It is like a conveyor belt that moves the code through different stages.
The CI pipeline is important because it shows us exactly what happens to the code from the moment it is added to when it is ready. It makes the process clear and repeatable.
Imagine you are making a sandwich. You follow steps: get bread, add spread, add filling, add another bread. Each step is part of the sandwich-making pipeline. A CI pipeline is similar but for code.
| Stage | What Happens | Simple Analogy |
|---|---|---|
| 1. Code Checkout | Get the latest code from the repository | Getting all the ingredients |
| 2. Build | Turn the code into a working program | Mixing the ingredients |
| 3. Test | Run tests to check the code works | Tasting the food |
| 4. Package | Prepare the program for deployment | Putting the food in a container |
| 5. Report | Tell the team the results | Announcing that the food is ready |
A team uses a CI pipeline that starts automatically when a developer pushes code. The pipeline checks out the code, builds it, runs 500 tests, packages it, and sends a report. The whole process takes 10 minutes.
Your class has a project pipeline: research, write, edit, submit. Each step must be completed before the next. A CI pipeline is like that but for code.
Your family has a dinner pipeline: plan the meal, buy ingredients, cook, serve, clean up. A CI pipeline is similar but for building software.
A Nigerian company has a CI pipeline that checks their code in 5 minutes. It runs tests on different devices and sends a report to the team. This helps them release new features quickly.
THE CI PIPELINE
+--------------------------------------------------+
| |
| STAGE 1: CODE CHECKOUT |
| +-------------------------------------------+ |
| | Get latest code from repository | |
| +-------------------------------------------+ |
| | |
| V |
| STAGE 2: BUILD |
| +-------------------------------------------+ |
| | Turn code into a working program | |
| +-------------------------------------------+ |
| | |
| V |
| STAGE 3: TEST |
| +-------------------------------------------+ |
| | Run tests to check everything works | |
| +-------------------------------------------+ |
| | |
| V |
| STAGE 4: PACKAGE |
| +-------------------------------------------+ |
| | Prepare program for deployment | |
| +-------------------------------------------+ |
| | |
| V |
| STAGE 5: REPORT |
| +-------------------------------------------+ |
| | Tell the team the results | |
| +-------------------------------------------+ |
| |
| 🔑 The CI pipeline automates everything! |
| |
+--------------------------------------------------+
A CI pipeline is the series of steps that CI follows to build and test the code. The stages are: code checkout, build, test, package, and report.
How CI works: CI works by automatically running a pipeline every time code is pushed to a repository. The pipeline builds the code, runs tests, and reports the results.
Understanding how CI works helps us use it effectively. We know what happens behind the scenes and can trust the results.
Imagine you have a robot helper. Every time you put a new piece into a puzzle, the robot checks to see if it fits. The robot looks at the shape, the color, and the edges. If everything is perfect, the robot says "Good job!" If something is wrong, the robot says "Fix this!"
CI is like that robot. It checks every piece of code automatically.
A developer pushes code to GitHub. GitHub Actions automatically starts a CI pipeline. It builds the code, runs tests, and sends a Slack message with the results. The developer sees the message and knows if everything is okay.
Your teacher has a system where every time you submit homework, it is automatically checked for errors. The system tells you if you made any mistakes so you can fix them. CI is like that for code.
Your family has a shopping list app. Every time someone adds an item, the app checks if the item is already on the list to avoid duplicates. CI is similar but for code.
A Nigerian company uses GitHub Actions for CI. Every time a developer pushes code, the CI pipeline runs. It builds the code, runs tests, and sends a report to the team's WhatsApp group. Everyone knows the status of the code instantly.
HOW CI WORKS
+--------------------------------------------------+
| |
| 1. DEVELOPER PUSHES CODE |
| +----------------------------------------+ |
| | git push origin main | |
| +----------------------------------------+ |
| | |
| V |
| 2. CI TOOL DETECTS CHANGE |
| +----------------------------------------+ |
| | GitHub Actions detects push | |
| | Jenkins detects change | |
| +----------------------------------------+ |
| | |
| V |
| 3. CODE IS CHECKED OUT |
| +----------------------------------------+ |
| | git clone the code | |
| +----------------------------------------+ |
| | |
| V |
| 4. CODE IS BUILT |
| +----------------------------------------+ |
| | Compile or build the code | |
| +----------------------------------------+ |
| | |
| V |
| 5. TESTS ARE RUN |
| +----------------------------------------+ |
| | Run automated tests | |
| +----------------------------------------+ |
| | |
| V |
| 6. RESULTS ARE REPORTED |
| +----------------------------------------+ |
| | ✅ PASSED or ❌ FAILED | |
| | Send email, Slack, or WhatsApp | |
| +----------------------------------------+ |
| | |
| V |
| 7. FIX IF NEEDED |
| +----------------------------------------+ |
| | Fix the problem and push again | |
| +----------------------------------------+ |
| |
+--------------------------------------------------+
CI works by automatically running a pipeline every time code is pushed. The pipeline builds the code, runs tests, and reports the results. If tests fail, the developer fixes the problem.
Jenkins is one of the most popular CI tools. It is an open-source tool that helps teams build, test, and deploy their code automatically.
Jenkins is important because it is free, powerful, and can be used for almost any project. Many companies around the world use Jenkins.
Imagine Jenkins as a super-smart factory worker. You tell Jenkins what to do (like "build this code and test it"), and Jenkins does it automatically every time there is new code. Jenkins never gets tired and never makes mistakes!
A company uses Jenkins to build their mobile app. Every time a developer pushes code, Jenkins automatically builds the app, runs tests, and packages it for release. The team gets an email with the results.
Your school has a robot that automatically checks homework. Students submit their work, and the robot checks it. Jenkins is like that robot but for code.
Your family has a smart assistant that automatically checks the shopping list and tells you if you are missing anything. Jenkins is like that but for code.
A Nigerian tech company uses Jenkins to test their web application. They have a Jenkins server running in Lagos. Every time a developer pushes code, Jenkins runs the tests and notifies the team.
JENKINS
+--------------------------------------------------+
| |
| JENKINS SERVER |
| +-------------------------------------------+ |
| | 🏗️ Builds the code | |
| | ✅ Runs tests | |
| | 📦 Packages the program | |
| | 📧 Sends results to the team | |
| +-------------------------------------------+ |
| | |
| V |
| +-------------------------------------------+ |
| | DEVELOPERS | |
| | Push code → Jenkins runs pipeline | |
| | Get results → Fix problems | |
| +-------------------------------------------+ |
| |
| 🔑 Jenkins = Free, open-source CI tool! |
| |
+--------------------------------------------------+
Jenkins is a popular open-source CI tool. It helps teams build, test, and deploy code automatically. It is free, powerful, and has many plugins.
GitHub Actions is a CI/CD tool that is built right into GitHub. It lets you automate your build, test, and deployment pipeline directly from your GitHub repository.
GitHub Actions is important because it is very easy to set up. If you already use GitHub, you can start using GitHub Actions in minutes.
Imagine you have a magic button on your GitHub repository. Every time you push code, you press the button, and it automatically builds and tests your code. GitHub Actions is like having that magic button!
A team using GitHub has a workflow that runs every time code is pushed. The workflow builds the code, runs tests, and deploys to a staging environment. The team gets a notification on Slack when it is done.
Your class has a shared Google Doc for projects. Every time someone adds to the doc, it is automatically checked for errors. GitHub Actions is like that but for code.
Your family has a shared shopping list. Every time someone adds an item, the app automatically checks if it is in stock. GitHub Actions is like that but for code.
A Nigerian startup uses GitHub Actions for CI. Their workflow runs tests on every pull request. If the tests pass, the code can be merged. This helps them maintain high quality code.
GITHUB ACTIONS
+--------------------------------------------------+
| |
| GITHUB REPOSITORY |
| +-------------------------------------------+ |
| | 📂 Project | |
| | ├── src | |
| | ├── tests | |
| | └── .github/workflows/ | |
| | └── ci.yml ← Workflow file | |
| +-------------------------------------------+ |
| | |
| V |
| GITHUB ACTIONS RUNS |
| +-------------------------------------------+ |
| | 🔄 Checks out code | |
| | 🏗️ Builds the code | |
| | ✅ Runs tests | |
| | 📧 Sends notifications | |
| +-------------------------------------------+ |
| | |
| V |
| RESULTS |
| +-------------------------------------------+ |
| | ✅ All tests passed! | |
| | ❌ Tests failed! | |
| +-------------------------------------------+ |
| |
| 🔑 GitHub Actions = CI built into GitHub! |
| |
+--------------------------------------------------+
GitHub Actions is a CI tool built right into GitHub. It lets you automate your build, test, and deployment pipeline directly from your GitHub repository. It is easy to set up and free for public repositories.
GitLab CI is a CI/CD tool that is built right into GitLab. It helps teams build, test, and deploy code automatically using GitLab's integrated DevOps platform.
GitLab CI is important because it is part of a complete DevOps platform. You can manage your code, run CI, and deploy your app all in one place.
Imagine you have a single app that does everything: stores your code, runs tests, and deploys your app. GitLab is like that. GitLab CI is the part that runs the tests and builds the code.
A company uses GitLab for everything. They store their code in GitLab, use GitLab CI for testing, and use GitLab for deployment. Everything is in one place.
Your school has a single portal for everything: assignments, grades, announcements, and communication. GitLab CI is like that but for building software.
Your family has a single app for all home management: shopping lists, calendars, and chores. GitLab CI is like that but for code.
A Nigerian company uses GitLab for their entire DevOps pipeline. They store their code in GitLab, run tests with GitLab CI, and deploy with GitLab. Everything is integrated and efficient.
GITLAB CI
+--------------------------------------------------+
| |
| GITLAB PLATFORM |
| +-------------------------------------------+ |
| | 📂 Code Repository | |
| | 🏗️ GitLab CI (Build & Test) | |
| | 🚀 GitLab Deploy (Deploy to servers) | |
| | 📊 GitLab Monitoring | |
| +-------------------------------------------+ |
| | |
| V |
| GITLAB CI RUNS |
| +-------------------------------------------+ |
| | 🔄 Checks out code | |
| | 🏗️ Builds the code | |
| | ✅ Runs tests | |
| | 📧 Sends notifications | |
| +-------------------------------------------+ |
| | |
| V |
| .gitlab-ci.yml FILE |
| +-------------------------------------------+ |
| | stages: | |
| | - build | |
| | - test | |
| | build_job: | |
| | stage: build | |
| | script: | |
| | - npm install | |
| | - npm run build | |
| +-------------------------------------------+ |
| |
| 🔑 GitLab CI = Integrated CI in GitLab! |
| |
+--------------------------------------------------+
GitLab CI is a CI tool built right into GitLab. It is part of a complete DevOps platform. You can manage your code, run CI, and deploy your app all in one place.
Automated testing is when you write code that tests your software automatically. These tests run without a human needing to do anything. In CI, automated tests are run every time code is pushed.
Automated testing is important because it catches problems immediately. Instead of a human testing the software manually, the computer does it automatically and much faster.
Imagine you have a robot that checks your homework. The robot looks at every question and checks your answers. It does this in seconds. The robot never gets tired and never makes mistakes. Automated testing is like having that robot for your code.
| Type of Test | What It Checks | Analogy |
|---|---|---|
| Unit Tests | Check small pieces of code (like a single function) | Checking one ingredient in a recipe |
| Integration Tests | Check if different parts of the code work together | Checking if all ingredients combine well |
| End-to-End Tests | Test the whole system like a real user | Tasting the final dish |
A banking app has thousands of automated tests. Every time a developer makes a change, all the tests run. They check if you can log in, check your balance, transfer money, and more.
Your teacher gives you a practice test. You take the test and check your answers. Automated testing is like having a computer check your answers for you.
Your family has a recipe. Every time you cook it, you check each ingredient. Automated testing is like having a machine check the ingredients for you.
A Nigerian e-commerce company has automated tests that run every time code is pushed. The tests check if the website loads, if you can add items to the cart, and if you can check out. This prevents problems for real customers.
AUTOMATED TESTING IN CI
+--------------------------------------------------+
| |
| UNIT TESTS |
| +-------------------------------------------+ |
| | ✅ checkUserLogin(user) | |
| | ✅ calculateTotal(items) | |
| | ✅ formatDate(date) | |
| +-------------------------------------------+ |
| |
| INTEGRATION TESTS |
| +-------------------------------------------+ |
| | ✅ User can log in | |
| | ✅ Items add to cart | |
| | ✅ Payment processes correctly | |
| +-------------------------------------------+ |
| |
| END-TO-END TESTS |
| +-------------------------------------------+ |
| | ✅ User logs in, adds item, and buys | |
| | ✅ User sees order confirmation | |
| +-------------------------------------------+ |
| |
| 🔑 All tests run automatically in CI! |
| |
+--------------------------------------------------+
Automated testing is when code tests your software automatically. In CI, automated tests run every time code is pushed. Types of tests include unit tests, integration tests, and end-to-end tests.
The benefits of CI are all the good things that happen when a team uses CI. These include fewer bugs, faster releases, and happier developers.
Understanding the benefits helps us see why CI is so valuable. It helps us understand why so many teams use CI.
Imagine you have a magic machine that checks your work for you. The machine finds mistakes immediately, tells you how to fix them, and saves you hours of work. CI is like having that magic machine for code!
| Benefit | What It Means |
|---|---|
| Fewer Bugs | Problems are caught and fixed early |
| Faster Releases | Because there are fewer bugs, releases are faster |
| Happy Developers | Developers spend less time fixing bugs and more time building |
| Happy Customers | Customers get reliable software with fewer problems |
| Less Stress | No more late-night bug fixes before a big release |
| Better Quality | Code is always tested, leading to higher quality |
| Team Confidence | Teams are confident that their code works |
A company adopted CI. Before CI, they had 100 bugs per release. After CI, they had only 5 bugs per release. Releases went from monthly to weekly. Everyone was happier.
Your class uses a system that checks homework automatically. You find and fix mistakes immediately. You learn faster and get better grades. CI is like that system.
Your family uses a smart system for planning. It catches mistakes in the plan and suggests improvements. Everything runs smoothly. CI is like that system.
A Nigerian fintech adopted CI. They used to have many bugs in their payment system. After CI, bugs decreased by 90%. Their customers trust them more, and the company has grown.
THE BENEFITS OF CI
+--------------------------------------------------+
| |
| 🐛 FEWER BUGS |
| Problems caught and fixed early |
| |
| 🚀 FASTER RELEASES |
| Releases happen more frequently |
| |
| 😊 HAPPY DEVELOPERS |
| Less time fixing bugs, more time building |
| |
| 😊 HAPPY CUSTOMERS |
| Reliable software with fewer problems |
| |
| 🧘 LESS STRESS |
| No more late-night emergency fixes |
| |
| 📈 BETTER QUALITY |
| Code is always tested and working |
| |
| 💪 TEAM CONFIDENCE |
| Teams are confident their code works |
| |
| ALL BECAUSE OF CI! 🎉 |
| |
+--------------------------------------------------+
CI has many benefits. It leads to fewer bugs, faster releases, happy developers, happy customers, less stress, better quality, and team confidence.
CI and DevOps: CI is a very important part of DevOps. It is one of the core practices that makes DevOps work. CI helps teams build, test, and integrate code continuously.
CI and DevOps work together to help teams deliver software faster and better. CI provides the automation, and DevOps provides the culture and processes.
Imagine DevOps is a big toolbelt. CI is one of the most important tools on that belt. Without CI, DevOps would be much harder. With CI, DevOps becomes powerful and effective.
A company uses DevOps practices including CI. Their developers push code frequently. CI automatically builds and tests the code. This is a key part of their DevOps pipeline.
Your school has a system for managing projects. CI is like the quality check part of the system. DevOps is the whole system including planning, execution, and review.
Your family has a system for managing the household. CI is like the weekly check that everything is in order. DevOps is the whole system including planning, budgeting, and chores.
A Nigerian company uses DevOps and CI. CI is the engine that drives their DevOps pipeline. Without CI, their DevOps would not work as well. Together, they deliver great software.
CI AND DEVOPS
+--------------------------------------------------+
| |
| DEVOPS = CULTURE + TOOLS + PROCESSES |
| +-------------------------------------------+ |
| | 📋 Plan | |
| | 💻 Code | |
| | 🏗️ BUILD ← CI is here! | |
| | ✅ Test ← CI is here! | |
| | 🚀 Release | |
| | 🔄 Deploy | |
| | 📊 Operate | |
| | 👀 Monitor | |
| +-------------------------------------------+ |
| | |
| V |
| CI IS A CORE PART OF DEVOPS |
| +-------------------------------------------+ |
| | ✅ CI automates building and testing | |
| | ✅ CI gives fast feedback | |
| | ✅ CI helps maintain quality | |
| +-------------------------------------------+ |
| |
| 🔑 CI + DevOps = Powerful software delivery! |
| |
+--------------------------------------------------+
CI is a very important part of DevOps. CI provides the automation for building and testing code. Together, CI and DevOps help teams deliver software faster and better.
In this lesson, we will review everything we have learned about Continuous Integration. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use CI every day. They push code, CI builds and tests it, and they get immediate feedback. Their software is high quality and released frequently.
Your class has learned about CI. They understand the importance of checking work early and often.
Your family has learned about CI. They understand the importance of checking plans and making adjustments early.
A Nigerian developer has learned all these CI concepts. They can now set up CI for their team and help their company deliver better software.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 CI = Automatically build and test code |
| 📌 CI catches problems early |
| 📌 CI pipeline has 5 stages |
| 📌 CI tools: Jenkins, GitHub Actions, GitLab |
| 📌 Automated testing finds problems |
| 📌 Benefits: fewer bugs, faster releases |
| 📌 CI is a core part of DevOps |
| |
| YOU ARE NOW A CI BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about Continuous Integration. CI helps teams build, test, and integrate code continuously. It is a core part of DevOps.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Continuous Integration (CI) | A practice where developers automatically build and test code every time they make a change |
| CI Pipeline | The series of steps that CI follows to build and test the code |
| Build | Turning code into a working program |
| Automated Testing | Code that tests your software automatically |
| Unit Test | A test that checks a small piece of code |
| Integration Test | A test that checks if different parts of code work together |
| End-to-End Test | A test that checks the whole system like a real user |
| Jenkins | A popular open-source CI tool |
| GitHub Actions | A CI tool built right into GitHub |
| GitLab CI | A CI tool built right into GitLab |
| Plugin | An add-on that adds extra features to a tool |
| Pipeline as Code | Defining your pipeline using code |
| Workflow | A defined set of steps in a CI pipeline |
| Report | A summary of the CI results |
| Automation | Making a process run automatically without human intervention |
Here are the most important concepts from this module. These are the big ideas that will help you understand Continuous Integration.
CI catches problems early. Instead of finding bugs weeks later, CI finds them immediately. This makes them easier and cheaper to fix.
The CI pipeline automates everything. From code checkout to testing to reporting, the CI pipeline does everything automatically. This saves time and reduces errors.
Automated testing is key. CI runs automated tests every time code is pushed. These tests check if the code works correctly.
CI tools are powerful. Jenkins, GitHub Actions, and GitLab CI are popular tools that help teams implement CI.
CI is part of DevOps. CI is a core practice in DevOps. It provides the automation for building and testing code.
CI benefits everyone. Developers, operations teams, and customers all benefit from CI. It leads to better software, faster releases, and happier people.
Let us look at how to set up and use CI in simple steps:
Decide which CI tool to use. Jenkins, GitHub Actions, and GitLab CI are all good choices. Pick the one that works best for your team.
Install and configure the CI tool. For GitHub Actions, this is very easy because it is already built into GitHub. For Jenkins, you need to download and install it.
Create a pipeline definition file. For Jenkins, this is a Jenkinsfile. For GitHub Actions, it is a workflow YAML file. For GitLab CI, it is a .gitlab-ci.yml file.
Define the stages of your pipeline. Typically: code checkout, build, test, package, and report. Specify what commands to run in each stage.
Push code to the repository. The CI tool will automatically detect the change and run the pipeline.
Check the results of the pipeline. If it passes, the code is good. If it fails, fix the problem and push again.
STEP-BY-STEP: SETTING UP CI
Step 1: CHOOSE A CI TOOL
+-------------------+
| Jenkins, GitHub |
| Actions, GitLab |
| CI |
+-------------------+
|
V
Step 2: SET UP THE TOOL
+-------------------+
| Install and |
| configure |
+-------------------+
|
V
Step 3: DEFINE PIPELINE
+-------------------+
| Create pipeline |
| definition file |
+-------------------+
|
V
Step 4: CONFIGURE PIPELINE
+-------------------+
| Define stages |
| (build, test, |
| etc.) |
+-------------------+
|
V
Step 5: RUN PIPELINE
+-------------------+
| Push code |
| CI runs |
| automatically |
+-------------------+
|
V
Step 6: REVIEW RESULTS
+-------------------+
| ✅ PASSED |
| ❌ FAILED |
+-------------------+
An e-commerce company uses GitHub Actions for CI. Every time a developer pushes code, the CI pipeline runs. It builds the website, runs 500 tests, and deploys to a staging environment. The team gets a Slack notification with the results.
A mobile app team uses Jenkins for CI. They have a Jenkins server that runs their pipeline. Every time code is pushed, Jenkins builds the app, runs tests on different devices, and packages it for release.
A bank uses GitLab CI for their core banking system. They have a complex pipeline with multiple stages. Every change is tested thoroughly before it is deployed. This ensures the banking system is always reliable.
Flutterwave, a Nigerian fintech company, uses CI to test their payment platform. Every time a developer adds code, CI runs thousands of tests. This helps them maintain high quality and prevent problems.
Paystack uses GitHub Actions for CI. Their pipeline builds the code, runs tests, and deploys to staging. If the tests pass, the code is ready for production. This helps them release new features quickly.
A Nigerian tech hub has many developers working on different projects. They use GitLab CI for all their projects. Each project has its own pipeline. The CI system helps them maintain quality across all projects.
Your teacher has a magic machine that checks your homework. Every time you submit your homework, the machine checks it and tells you if you made any mistakes. You can fix them immediately and get a better grade. CI is like that magic machine!
You are building a puzzle. Every time you add a new piece, a robot checks to see if it fits. If it does not fit, the robot tells you immediately. You can fix it before the puzzle gets too complicated. CI is like that robot!
You are cooking a meal. Every time you add a new ingredient, you taste it to make sure it is good. If it is not, you can fix it. CI is like tasting your food while cooking.
Your family has a shopping list. Every time someone adds an item, the app checks if it is already on the list to avoid duplicates. CI is similar but for code.
Your family has a shared calendar. Every time someone adds an event, the calendar checks for conflicts. If there is a conflict, you are told immediately. CI is like that but for code.
Your family has a budget. Every time someone adds an expense, the budget is updated and checked. If you are overspending, you are told immediately. CI is like that but for code.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about Continuous Integration and how it helps teams build software. Here are some tips to support their learning:
Mistake 1: Not running tests locally first.
Developers should run tests locally before pushing. If a test fails on the CI server, it wastes everyone's time. Running tests locally catches problems first.
Mistake 2: Ignoring CI failures.
If the CI pipeline fails, fix it immediately. Ignoring it means more bugs will be introduced.
Mistake 3: Making the pipeline too slow.
If the CI pipeline takes too long, developers will not want to use it. Keep the pipeline fast by running tests in parallel and optimizing.
Mistake 4: Not testing enough.
If you do not have enough tests, bugs will slip through. Write tests for all important parts of your code.
Mistake 5: Having a fragile pipeline.
If the pipeline breaks frequently, developers will lose confidence. Keep the pipeline stable and reliable.
Mistake 6: Not using CI for all projects.
CI should be used for all projects, big and small. Even small projects benefit from CI.
Run tests locally first.
Before pushing code, run tests on your own computer. This catches problems before they reach the CI server.
Keep the pipeline fast.
A fast pipeline encourages developers to use it. Run tests in parallel and use caching to speed things up.
Write comprehensive tests.
Write tests for all important parts of your code. This includes unit tests, integration tests, and end-to-end tests.
Keep the pipeline stable.
Make sure the pipeline is reliable. If it breaks often, developers will lose confidence in it.
Use CI for all projects.
CI is beneficial for all projects, not just large ones. Even small projects benefit from automated testing.
Review CI results.
Always review the CI results. If it passes, your code is good. If it fails, fix the problem immediately.
Monitor CI usage.
Keep track of how CI is used. Look for ways to improve the pipeline and make it even better.
THE CI PIPELINE
+--------------------------------------------------+
| |
| CODE CHECKOUT |
| +-------------------------------------------+ |
| | Get latest code from repository | |
| +-------------------------------------------+ |
| | |
| V |
| BUILD |
| +-------------------------------------------+ |
| | Turn code into a working program | |
| +-------------------------------------------+ |
| | |
| V |
| TEST |
| +-------------------------------------------+ |
| | Run automated tests | |
| +-------------------------------------------+ |
| | |
| V |
| PACKAGE |
| +-------------------------------------------+ |
| | Prepare program for deployment | |
| +-------------------------------------------+ |
| | |
| V |
| REPORT |
| +-------------------------------------------+ |
| | Tell the team the results | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
CI TOOLS
+--------------------------------------------------+
| |
| JENKINS |
| +-------------------------------------------+ |
| | Open-source, free, powerful | |
| | Thousands of plugins | |
| | Pipeline as Code | |
| +-------------------------------------------+ |
| |
| GITHUB ACTIONS |
| +-------------------------------------------+ |
| | Built into GitHub | |
| | Easy to set up | |
| | Free for public repos | |
| +-------------------------------------------+ |
| |
| GITLAB CI |
| +-------------------------------------------+ |
| | Built into GitLab | |
| | Complete DevOps platform | |
| | Free for private repos | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
CI BENEFITS
+--------------------------------------------------+
| |
| 🐛 FEWER BUGS |
| Problems caught and fixed early |
| |
| 🚀 FASTER RELEASES |
| Releases happen more frequently |
| |
| 😊 HAPPY DEVELOPERS |
| Less time fixing bugs, more time building |
| |
| 😊 HAPPY CUSTOMERS |
| Reliable software with fewer problems |
| |
| 🧘 LESS STRESS |
| No more late-night emergency fixes |
| |
| 📈 BETTER QUALITY |
| Code is always tested and working |
| |
+--------------------------------------------------+
| Aspect | Without CI | With CI |
|---|---|---|
| Bug Discovery | Bugs found late (weeks or months later) | Bugs found immediately |
| Bug Fixing | Hard and expensive to fix | Easy and cheap to fix |
| Release Speed | Slow (months between releases) | Fast (days or weeks between releases) |
| Developer Experience | Frustrating, fixing others' bugs | Happy, fixing their own bugs quickly |
| Quality | Lower quality, more bugs | Higher quality, fewer bugs |
| Customer Experience | Unhappy, buggy software | Happy, reliable software |
| Feature | Jenkins | GitHub Actions | GitLab CI |
|---|---|---|---|
| Cost | Free (open-source) | Free for public repos | Free for private repos (with limits) |
| Setup Complexity | Medium (requires installation) | Very easy (built into GitHub) | Easy (built into GitLab) |
| Pipeline as Code | Jenkinsfile | Workflow YAML | .gitlab-ci.yml |
| Plugins/Extensions | Thousands of plugins | Thousands of actions | Integrated features |
| Self-Hosted Option | Yes | No (GitHub Enterprise available) | Yes |
| Popularity | Very popular | Rapidly growing | Popular in DevOps teams |
| Test Type | What It Checks | Speed | Analogy |
|---|---|---|---|
| Unit Test | Small pieces of code (functions, methods) | Very fast (milliseconds) | Checking one ingredient |
| Integration Test | How different parts work together | Fast (seconds) | Checking ingredients combine |
| End-to-End Test | Complete system like a real user | Slower (minutes) | Tasting the final dish |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 3 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change. It catches problems early, making them easier and cheaper to fix.
The CI pipeline is the series of steps that CI follows to build and test the code. The stages are: code checkout, build, test, package, and report. The pipeline runs automatically every time code is pushed.
We learned about three popular CI tools: Jenkins (open-source, powerful), GitHub Actions (built into GitHub, easy to set up), and GitLab CI (integrated into GitLab, part of a complete DevOps platform).
Automated testing is a key part of CI. Tests run automatically every time code is pushed. Types of tests include unit tests, integration tests, and end-to-end tests.
CI leads to fewer bugs, faster releases, happy developers, happy customers, less stress, better quality, and team confidence. It is a core practice in DevOps.
You have now completed Module 3! You are ready to move on to Module 4, where you will learn about Continuous Delivery and Deployment (CD). Keep up the great work!
Q1: What is Continuous Integration?
A: Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change. It catches problems early.
Q2: Why is CI important?
A: CI is important because it catches problems early. Bugs are found immediately, making them easier and cheaper to fix.
Q3: What is a CI pipeline?
A: A CI pipeline is the series of steps that CI follows to build and test the code. It includes code checkout, build, test, package, and report.
Q4: What are some popular CI tools?
A: Popular CI tools include Jenkins, GitHub Actions, and GitLab CI.
Q5: What is automated testing?
A: Automated testing is when code tests your software automatically. In CI, automated tests run every time code is pushed.
Q6: What are the benefits of CI?
A: CI leads to fewer bugs, faster releases, happy developers, happy customers, less stress, better quality, and team confidence.
Q7: Is CI part of DevOps?
A: Yes, CI is a core part of DevOps. It provides the automation for building and testing code.
Q8: Which CI tool should I use?
A: It depends on your needs. Jenkins is good for complex projects. GitHub Actions is great if you use GitHub. GitLab CI is excellent if you use GitLab.
Q9: Can CI run tests on different platforms?
A: Yes, CI can run tests on different operating systems (Windows, Linux, Mac) and different environments.
Q10: Is CI used in Nigeria?
A: Yes, many Nigerian companies use CI. It is helping them deliver better software and compete globally.
What is Continuous Integration?
Answer: Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change.
Why do we need CI?
Answer: We need CI because it catches problems early, making them easier and cheaper to fix.
What is the CI pipeline?
Answer: The CI pipeline is the series of steps that CI follows to build and test the code.
What are the stages of a CI pipeline?
Answer: The stages are: code checkout, build, test, package, and report.
What does "build" mean in CI?
Answer: Build means turning the code into a working program.
What is automated testing?
Answer: Automated testing is when code tests your software automatically.
Name three types of automated tests.
Answer: Unit tests, integration tests, and end-to-end tests.
What is a unit test?
Answer: A unit test checks a small piece of code, like a single function.
What is an end-to-end test?
Answer: An end-to-end test checks the whole system like a real user.
Name three popular CI tools.
Answer: Jenkins, GitHub Actions, and GitLab CI.
What is Jenkins?
Answer: Jenkins is a popular open-source CI tool.
What is GitHub Actions?
Answer: GitHub Actions is a CI tool built right into GitHub.
What is GitLab CI?
Answer: GitLab CI is a CI tool built right into GitLab.
What are two benefits of CI?
Answer: Fewer bugs and faster releases. (Other answers: happy developers, happy customers, less stress, better quality, team confidence.)
Is CI part of DevOps?
Answer: Yes, CI is a core part of DevOps.
Fill in the blanks with the correct words from the list:
Word list: Continuous Integration, pipeline, build, automated testing, unit test, integration test, end-to-end test, Jenkins, GitHub Actions, GitLab CI, DevOps, report
__________ is a practice where developers automatically build and test their code every time they make a change.
Answer: Continuous Integration
The CI __________ is the series of steps that CI follows to build and test the code.
Answer: pipeline
To __________ the code means to turn it into a working program.
Answer: build
__________ is when code tests your software automatically.
Answer: automated testing
A __________ checks a small piece of code, like a single function.
Answer: unit test
An __________ checks the whole system like a real user.
Answer: end-to-end test
__________ is a popular open-source CI tool.
Answer: Jenkins
__________ is a CI tool built right into GitHub.
Answer: GitHub Actions
__________ is a CI tool built right into GitLab.
Answer: GitLab CI
CI is a core part of __________.
Answer: DevOps
Write True or False for each statement:
CI stands for Continuous Integration.
Answer: True
CI catches problems late, making them harder to fix.
Answer: False (CI catches problems early)
The CI pipeline has 5 stages: code checkout, build, test, package, and report.
Answer: True
Jenkins is a CI tool built into GitHub.
Answer: False (Jenkins is a separate tool. GitHub Actions is built into GitHub.)
GitHub Actions is built into GitHub.
Answer: True
GitLab CI is built into GitLab.
Answer: True
Automated testing is not part of CI.
Answer: False (Automated testing is a key part of CI)
Unit tests check the whole system.
Answer: False (Unit tests check small pieces of code)
CI leads to faster releases.
Answer: True
CI is not part of DevOps.
Answer: False (CI is a core part of DevOps)
CI helps catch problems early.
Answer: True
The "report" stage of the CI pipeline tells the team the results.
Answer: True
CI is only useful for large projects.
Answer: False (CI is useful for all projects)
GitLab CI is a CI tool built into GitLab.
Answer: True
CI is used in Nigeria.
Answer: True
Choose the correct answer for each question:
What is Continuous Integration?
A) A type of computer
B) A practice where developers automatically build and test
their code
C) A programming language
D) A video game
Answer: B
Why is CI important?
A) It makes code slower
B) It catches problems early
C) It makes developers work harder
D) It is not important
Answer: B
How many stages does the CI pipeline have?
A) 3
B) 4
C) 5
D) 6
Answer: C
Which is a stage in the CI pipeline?
A) Play
B) Build
C) Sleep
D) Eat
Answer: B
What does "build" mean in CI?
A) Breaking the code
B) Turning code into a working program
C) Deleting the code
D) Copying the code
Answer: B
What is automated testing?
A) Testing done by humans
B) Code that tests your software automatically
C) Testing that is never done
D) Testing that is done manually
Answer: B
Which is a type of automated test?
A) Manual test
B) Unit test
C) Paper test
D) Verbal test
Answer: B
What is a unit test?
A) A test that checks the whole system
B) A test that checks a small piece of code
C) A test that is done manually
D) A test that is never run
Answer: B
What is an end-to-end test?
A) A test that checks the whole system like a real user
B) A test that checks a small piece of code
C) A test that is done manually
D) A test that is never run
Answer: A
Which is a popular CI tool?
A) Jenkins
B) Microsoft Word
C) Google Chrome
D) WhatsApp
Answer: A
Which CI tool is built into GitHub?
A) Jenkins
B) GitHub Actions
C) GitLab CI
D) Travis CI
Answer: B
Which CI tool is built into GitLab?
A) Jenkins
B) GitHub Actions
C) GitLab CI
D) Travis CI
Answer: C
Is CI part of DevOps?
A) No
B) Yes, it is a core part
C) Sometimes
D) Only for large companies
Answer: B
What is a benefit of CI?
A) More bugs
B) Slower releases
C) Fewer bugs
D) Unhappy customers
Answer: C
Is CI used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Continuous Integration | A. A practice where developers automatically build and test code |
| 2. CI Pipeline | B. Turning code into a working program |
| 3. Build | C. The series of steps to build and test code |
| 4. Automated Testing | D. A test that checks a small piece of code |
| 5. Unit Test | E. Code that tests your software automatically |
| 6. Integration Test | F. A test that checks the whole system like a user |
| 7. End-to-End Test | G. A test that checks if parts work together |
| 8. Jenkins | H. A CI tool built into GitHub |
| 9. GitHub Actions | I. A CI tool built into GitLab |
| 10. GitLab CI | J. A popular open-source CI tool |
Answers:
What is Continuous Integration and why is it useful?
Answer: Continuous Integration (CI) is a practice where developers automatically build and test their code every time they make a change. It is useful because it catches problems early, making them easier and cheaper to fix. It leads to fewer bugs and faster releases.
Explain the stages of a CI pipeline.
Answer: The CI pipeline has five stages:
What are the differences between unit tests, integration tests, and end-to-end tests?
Answer: Unit tests check small pieces of code (like a single function). Integration tests check if different parts of the code work together. End-to-end tests check the whole system like a real user. Unit tests are the fastest, and end-to-end tests are the slowest.
Compare Jenkins, GitHub Actions, and GitLab CI.
Answer: Jenkins is a popular open-source CI tool with many plugins. GitHub Actions is built into GitHub and is very easy to set up. GitLab CI is built into GitLab and is part of a complete DevOps platform. Jenkins requires installation, while GitHub Actions and GitLab CI are already integrated.
How does CI support DevOps?
Answer: CI is a core part of DevOps. It provides the automation for building and testing code. CI gives fast feedback to developers, helps maintain quality, and encourages collaboration between developers and operations. CI is the engine that drives the DevOps pipeline.
A company has an app that keeps crashing. Developers find bugs late, and fixing them takes a long time. Customers are frustrated. The company wants to improve.
Question: How could CI help this company?
Answer: CI could help by automatically building and testing the code every time a developer makes a change. Bugs would be found immediately, not weeks later. Developers would fix problems early when they are easy to fix. The app would become more stable, and customers would be happier.
A Nigerian company takes 3 months to release each new version of their software. They spend most of that time fixing bugs. They want to release faster.
Question: How would CI help them release faster?
Answer: CI would help by catching bugs early. Developers would fix them immediately, reducing the time spent fixing bugs. The company could release software more frequently — perhaps every week instead of every 3 months. CI would also give the team confidence that the code is working.
A Nigerian startup has 3 developers. They use GitHub for their code but do not use any CI. They often discover problems after merging code. They want to improve their process.
Question: What should the startup do to implement CI?
Answer: The startup should set up GitHub Actions, which is built into GitHub. They would create a workflow file that defines their CI pipeline. Every time a developer pushes code, GitHub Actions would automatically build and test it. This would catch problems immediately and help them deliver better software.
Instructions:
Instructions:
Why do you think catching problems early is important?
Discuss with your classmates and share your ideas.
Have you ever found a problem late in a project? How did it make you feel?
Share your experiences and thoughts.
What are some other situations where automation is helpful?
Think about school, home, and other activities.
Why do you think GitHub Actions is becoming so popular?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from CI?
Share examples of companies in Nigeria.
What do you think is the most important part of the CI pipeline?
Explain why you think so.
Do you think CI is easy to set up? Why or why not?
Share your thoughts.
What is the most important thing you learned about CI today?
Share with the class.
Goal: Create a simple guide to teach beginners about Continuous Integration.
Instructions:
Goal: Practice setting up a simple CI pipeline.
Instructions:
Scenario:
You are a CI architect at a Nigerian company. The company has 20 developers working on a large web application. They want to implement CI to improve their development process.
The company has:
Challenge: Create a complete CI implementation plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 3: "Continuous Integration (CI)." You now understand how CI helps teams automatically build and test their code every time they make a change.
In Module 4, you will learn:
Before you start Module 4, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 4! 🚀
© 2026 Certified DevOps Engineer Course • Module 3: Continuous Integration (CI)
Welcome to Module 4 of our Certified DevOps Engineer course! This module is called "Continuous Delivery & Deployment (CD): Releasing Software Automatically."
In this module, we will learn about Continuous Delivery and Continuous Deployment — two practices that help teams release software quickly, safely, and automatically.
Think of CD like having a magic conveyor belt that takes your finished product and delivers it to your customers automatically. Every time you finish something, it goes straight to the people who need it, without any delays!
Hello and welcome back! In Module 1, we learned about DevOps. In Module 2, we learned about Git. In Module 3, we learned about Continuous Integration (CI). Now, in Module 4, we are going to learn about Continuous Delivery (CD) and Continuous Deployment (CD).
Imagine you are baking cookies. You mix the dough, bake them, and they come out of the oven. Now you need to get them to your customers. You could wait and deliver them all at once, or you could have a system that automatically packages and sends them as soon as they are ready. That is what CD does for software!
In this module, we will learn all about CD — what it is, why it is important, how it works, and what strategies teams use to deploy software safely. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover how software gets from developers to users automatically!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company called "QuickDeliver" that delivered food to people's homes. They were very good at cooking, but they had a big problem with delivery.
Every time the kitchen finished cooking a meal, someone had to manually pack it, find a driver, and send it out. This took a long time. Sometimes meals got cold. Sometimes drivers got lost. Customers were not happy.
One day, the owner of QuickDeliver, a woman named Mrs. Bola, decided to build an automatic delivery system. The system would:
With this system, every meal was delivered immediately. Customers got fresh, hot food. The company grew and became the most popular food delivery service in Lagos.
This story shows us how automatic delivery can make a huge difference. Continuous Delivery and Continuous Deployment are exactly like that for software — they automatically deliver new features to users as soon as they are ready.
Let us learn more about how this works!
Continuous Delivery (CD) is a practice where software is always ready to be released to users. Every change that passes all tests is automatically prepared for release. A human still decides when to actually release it.
Continuous Delivery is important because it makes releasing software easy and safe. Instead of spending days preparing for a release, the software is always ready. You can release anytime you want.
Imagine you are baking cookies. You bake a batch, and they are perfect. You put them in a special box that keeps them fresh. They are ready to be given to customers anytime. You just need to decide when to hand them over. Continuous Delivery is like having your cookies always ready in that special box!
A company builds a mobile app. Every time a developer fixes a bug or adds a feature, the code is automatically built, tested, and packaged. It is always ready to be released to the app store. The team decides when to release it.
Your class is working on a newspaper. Every time an article is finished and edited, it is placed in a "ready to publish" folder. The teacher decides when to print the newspaper. Continuous Delivery is like having everything ready to print at any time.
Your family is planning a party. Everything is prepared — the food is cooked, the decorations are up, and the music is ready. The party can start anytime you decide. Continuous Delivery is like having the party always ready to start.
A Nigerian fintech company uses Continuous Delivery. Every change to their payment system is automatically built and tested. It is always ready to be released. The team decides when to release new features, often after they have been tested by a small group of users.
CONTINUOUS DELIVERY
+--------------------------------------------------+
| |
| DEVELOPER MAKES A CHANGE |
| +-------------------------------------------+ |
| | Code is pushed | |
| +-------------------------------------------+ |
| | |
| V |
| CI RUNS |
| +-------------------------------------------+ |
| | Build and test the code | |
| +-------------------------------------------+ |
| | |
| V |
| PACKAGE FOR RELEASE |
| +-------------------------------------------+ |
| | Code is packaged and ready | |
| | Always ready to be released! | |
| +-------------------------------------------+ |
| | |
| V |
| HUMAN DECIDES WHEN TO RELEASE |
| +-------------------------------------------+ |
| | ✅ "Release now!" or ⏳ "Wait" | |
| +-------------------------------------------+ |
| | |
| V |
| RELEASE |
| +-------------------------------------------+ |
| | Software is released to users | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
Continuous Delivery (CD) is a practice where software is always ready to be released. Every change is automatically built and tested, but a human decides when to actually release it.
Continuous Deployment is a practice where every change that passes all tests is automatically released to users. No human approval is needed — it happens automatically!
Continuous Deployment takes automation to the next level. It means that new features and fixes reach users as soon as they are ready. This is the fastest way to deliver value to customers.
Imagine you are baking cookies. Every time a batch comes out of the oven and is perfect, a robot automatically puts them in a box and delivers them to a customer. You do not need to do anything — it all happens automatically. Continuous Deployment is like having that robot!
A company uses Continuous Deployment for their website. Every time a developer pushes code and all tests pass, the new code is automatically deployed to the live website. Users see the changes within minutes.
Your class has a blog. Every time you finish writing and editing a post, it is automatically published on the blog. No one has to click "publish" — it just happens. Continuous Deployment is like that!
Your family has a smart home system. Every time you add a new device, it is automatically configured and connected. Continuous Deployment is like that — everything happens automatically.
A Nigerian startup uses Continuous Deployment for their mobile app. Every time a developer fixes a bug, the fix is automatically sent to all users. Users always have the latest version.
CONTINUOUS DEPLOYMENT
+--------------------------------------------------+
| |
| DEVELOPER MAKES A CHANGE |
| +-------------------------------------------+ |
| | Code is pushed | |
| +-------------------------------------------+ |
| | |
| V |
| CI RUNS |
| +-------------------------------------------+ |
| | Build and test the code | |
| +-------------------------------------------+ |
| | |
| V |
| DOES IT PASS ALL TESTS? |
| +-------------------------------------------+ |
| | ✅ YES → Go to deployment | |
| | ❌ NO → Fix the code | |
| +-------------------------------------------+ |
| | |
| V |
| AUTOMATIC DEPLOYMENT |
| +-------------------------------------------+ |
| | 🚀 Code is deployed to users | |
| | Automatically! No human needed! | |
| +-------------------------------------------+ |
| | |
| V |
| USERS GET NEW FEATURES INSTANTLY |
| +-------------------------------------------+ |
| | 😊 Happy users! | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
Continuous Deployment is a practice where every change that passes all tests is automatically released to users. No human approval is needed. It is the fastest way to deliver value to customers.
CI (Continuous Integration) is about automatically building and testing code. CD (Continuous Delivery) is about keeping code ready to release. Continuous Deployment is about automatically releasing code to users.
Understanding the difference helps us know which practice to use in different situations. Some teams use CI and CD, while others use Continuous Deployment.
Imagine you are building a toy. CI is like checking each piece as you put it together to make sure it fits. CD is like having the finished toy ready in a box, waiting to be given to a child. Continuous Deployment is like giving the toy to the child as soon as it is finished.
| Practice | What It Does | Human Involved? |
|---|---|---|
| Continuous Integration (CI) | Automatically builds and tests code | No |
| Continuous Delivery (CD) | Keeps code ready to release | Yes (decides when to release) |
| Continuous Deployment | Automatically releases code to users | No |
A company uses CI, Continuous Delivery, and sometimes Continuous Deployment. They use CI to test all changes. They use Continuous Delivery to keep everything ready. For some projects, they use Continuous Deployment to automatically release updates.
Your class has a project workflow:
Your family plans a vacation:
A Nigerian company uses CI and Continuous Delivery for their banking app. They want human approval before releasing because it is a critical system. For their marketing website, they use Continuous Deployment because it is less risky.
CI VS CD VS CONTINUOUS DEPLOYMENT
+--------------------------------------------------+
| |
| CI (Continuous Integration) |
| +-------------------------------------------+ |
| | Automatically build and test code | |
| | "Make sure it works!" | |
| +-------------------------------------------+ |
| |
| CD (Continuous Delivery) |
| +-------------------------------------------+ |
| | Keep code ready to release | |
| | "Always ready to go!" | |
| +-------------------------------------------+ |
| |
| Continuous Deployment |
| +-------------------------------------------+ |
| | Automatically release to users | |
| | "Deploy automatically!" | |
| +-------------------------------------------+ |
| |
| CI + CD + Continuous Deployment = CI/CD! |
| |
+--------------------------------------------------+
CI is about building and testing code. Continuous Delivery is about keeping code ready to release. Continuous Deployment is about automatically releasing code to users.
A CI/CD pipeline is the complete series of steps that code goes through from the moment it is written to the moment it is released to users. It combines CI, CD, and sometimes Continuous Deployment into one continuous flow.
The CI/CD pipeline is important because it shows the entire journey of the code. It makes the process clear and automated, from writing code to delivering it to users.
Imagine you are making a toy. The CI/CD pipeline is the whole process from designing the toy to putting it in a box to giving it to a child. Each step happens automatically in the right order.
| Stage | What Happens | Analogy |
|---|---|---|
| 1. Code | Developer writes and pushes code | Designing the toy |
| 2. Build | Code is compiled or built | Making the toy parts |
| 3. Test | Automated tests run | Checking the toy works |
| 4. Package | Code is packaged for release | Putting the toy in a box |
| 5. Release | Code is prepared for release | Ready to give the toy |
| 6. Deploy | Code is deployed to servers | Giving the toy to the child |
| 7. Monitor | Code is monitored for problems | Checking if the child likes it |
A company has a CI/CD pipeline that runs every time code is pushed. The pipeline builds the code, runs tests, packages it, and deploys it to staging. After approval, it deploys to production. The whole pipeline takes 15 minutes.
Your school has a project pipeline: research, write, edit, submit, and receive feedback. Each step must be completed before the next. A CI/CD pipeline is like that but for code.
Your family has a dinner pipeline: plan, shop, cook, serve, eat, clean. A CI/CD pipeline is similar but for building and releasing software.
A Nigerian company has a CI/CD pipeline that runs on GitLab. It starts when a developer pushes code, runs tests, builds the app, and deploys to their servers in Lagos. The whole process is automated.
THE CI/CD PIPELINE
+--------------------------------------------------+
| |
| CODE |
| +-------------------------------------------+ |
| | Developer writes and pushes code | |
| +-------------------------------------------+ |
| | |
| V |
| BUILD |
| +-------------------------------------------+ |
| | Code is compiled or built | |
| +-------------------------------------------+ |
| | |
| V |
| TEST |
| +-------------------------------------------+ |
| | Automated tests run | |
| +-------------------------------------------+ |
| | |
| V |
| PACKAGE |
| +-------------------------------------------+ |
| | Code is packaged for release | |
| +-------------------------------------------+ |
| | |
| V |
| RELEASE |
| +-------------------------------------------+ |
| | Code is prepared for release | |
| +-------------------------------------------+ |
| | |
| V |
| DEPLOY |
| +-------------------------------------------+ |
| | Code is deployed to servers | |
| +-------------------------------------------+ |
| | |
| V |
| MONITOR |
| +-------------------------------------------+ |
| | Code is monitored for problems | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
A CI/CD pipeline is the complete series of steps from writing code to releasing it to users. It combines CI, CD, and monitoring into one automated flow.
A deployment strategy is a plan for how software is released to users. Different strategies are used depending on how important it is to avoid problems.
Deployment strategies are important because they help teams release software safely. If something goes wrong, a good strategy makes sure fewer users are affected and the problem can be fixed quickly.
Imagine you are giving out new toys to children. You could give one toy to one child first to see if they like it. If they do, you give toys to more children. If they do not, you fix the toy first. Deployment strategies are like that — they let you test new software safely.
| Strategy | What It Is | Analogy | Risk |
|---|---|---|---|
| Rolling Update | Updates servers one at a time | Fixing tires one at a time while driving | Low |
| Blue-Green Deployment | Switches from old to new version at once | Switching tracks on a train | Medium |
| Canary Release | Updates a small group of users first | Testing a new food on a small group first | Very low |
| Rollback | Goes back to the old version if problems | Undoing a change | Safe |
A company uses a canary release for their new feature. They deploy it to 1% of users first. If there are no problems, they increase to 10%, then 50%, then 100%. This way, if there is a problem, only a few users are affected.
Your school is trying a new schedule. They test it with one class first (canary). If it works, they roll it out to all classes (rolling update).
Your family is trying a new recipe. You make a small portion first (canary). If it tastes good, you make a larger portion (rolling update).
A Nigerian bank uses blue-green deployment for their mobile app. They have two identical environments: "blue" (live) and "green" (new). They deploy the new version to green, test it, and then switch users from blue to green. If there is a problem, they switch back instantly.
DEPLOYMENT STRATEGIES
ROLLING UPDATE:
+--------------------------------------------------+
| Server 1: Old → New |
| Server 2: Old → New |
| Server 3: Old → New |
| (One at a time, like changing tires) |
+--------------------------------------------------+
BLUE-GREEN DEPLOYMENT:
+--------------------------------------------------+
| Blue (Live): Old version |
| Green (New): New version |
| Switch users from Blue to Green instantly! |
+--------------------------------------------------+
CANARY RELEASE:
+--------------------------------------------------+
| 1% Users → New version |
| ✅ If good → 10% Users |
| ✅ If good → 50% Users |
| ✅ If good → 100% Users |
+--------------------------------------------------+
Deployment strategies are plans for releasing software safely. Common strategies include rolling updates, blue-green deployments, and canary releases. They help teams avoid problems and fix issues quickly.
An artifact is the packaged version of your code that is ready to be deployed. It is like the final product that comes out of the build process.
Artifacts are important because they are what actually gets deployed. Managing artifacts well means you always know which version is running and can go back to older versions if needed.
Imagine you are baking cookies. The final, baked cookies are the "artifacts." You package them in a box. Each batch has a date and a number so you know which batch is which. Artifact management is like keeping track of all your cookie batches!
A company uses an artifact repository called JFrog Artifactory. Every time their CI pipeline runs, it produces an artifact with a version number. The deployment process uses this artifact to deploy to servers.
Your class has a final project submission. Each version of the project is saved with a date and version number. This is like managing artifacts.
Your family saves photos from each vacation. Each folder has the date and location. This is like managing artifacts.
A Nigerian company stores all their artifacts in a repository. They can deploy any previous version anytime. This helps them quickly fix problems by going back to a working version.
ARTIFACT MANAGEMENT
+--------------------------------------------------+
| |
| ARTIFACT REPOSITORY |
| +-------------------------------------------+ |
| | 📦 my-app-v1.0.0.zip | |
| | 📦 my-app-v1.0.1.zip | |
| | 📦 my-app-v1.1.0.zip | |
| | 📦 my-app-v2.0.0.zip | |
| | 📦 my-app-v2.0.1.zip | |
| +-------------------------------------------+ |
| |
| Each artifact has: |
| +-------------------------------------------+ |
| | ✅ Version number | |
| | ✅ Build date | |
| | ✅ Build ID | |
| | ✅ Size and checksum | |
| +-------------------------------------------+ |
| |
| 🔑 Artifacts are versioned and stored! |
| You can deploy any version anytime. |
| |
+--------------------------------------------------+
An artifact is the packaged version of your code ready to be deployed. Artifact management is the practice of storing and versioning these packages so you can deploy any version anytime.
Release governance is the set of rules and approvals that must be followed before software can be released. It is like a checklist that must be completed before a release.
Release governance is important because it makes sure releases are safe and follow the rules. It helps prevent problems by making sure everything is checked before release.
Imagine you are a pilot getting ready to fly a plane. Before you take off, you have a checklist: check the fuel, check the weather, check the engines, and get approval from the control tower. Release governance is like that checklist for software releases.
A company has a release governance policy. Before any release, a senior developer must approve, all tests must pass, and there must be a rollback plan. This ensures the release is safe.
Your school has a policy for submitting projects. You must have your work reviewed by a teacher, have a cover page, and submit it on time. This is like release governance.
Your family has rules for planning a party. You must get approval from everyone, have enough food, and have a backup plan. This is like release governance.
A Nigerian bank has strict release governance. Every release must be approved by the security team, the compliance team, and a senior manager. This ensures the bank's systems are secure and follow regulations.
RELEASE GOVERNANCE
+--------------------------------------------------+
| RELEASE CHECKLIST |
| |
| ☑ All tests pass |
| ☑ Code reviewed by another developer |
| ☑ Manager approval |
| ☑ Compliance team approval |
| ☑ Documentation updated |
| ☑ Rollback plan is ready |
| ☑ Release notes are written |
| ☑ Security checks pass |
| |
| ✅ ALL CLEAR: READY TO RELEASE! |
| |
| 🔑 Governance makes releases safe and compliant! |
| |
+--------------------------------------------------+
Release governance is the set of rules and approvals that must be followed before a release. It ensures releases are safe, compliant, and well-prepared.
The benefits of CD are all the good things that happen when a team uses Continuous Delivery and Continuous Deployment.
Understanding the benefits helps us see why CD is so valuable. It helps us understand why so many teams are adopting CD.
Imagine you have a magic machine that delivers your finished work to customers instantly. You never have to worry about delivery. You just focus on making great things. CD is like having that magic machine!
| Benefit | What It Means |
|---|---|
| Faster Releases | New features reach users much faster |
| Less Risk | Small releases are safer than big releases |
| Quick Fixes | Bugs can be fixed and released in minutes |
| Happy Users | Users get new features and fixes quickly |
| Less Stress | No more stressful big release days |
| Better Quality | Frequent releases mean faster feedback |
| Team Confidence | Teams are confident they can release anytime |
A company adopted Continuous Deployment. Before, they released updates once a month. Now, they release updates several times a day. Bugs are fixed in minutes, not weeks. Customers are much happier.
Your class uses CD for a group project. Instead of waiting until the end to submit, you submit sections as they are finished. You get feedback faster and can improve more quickly.
Your family uses CD for planning. Instead of waiting until the last minute to book everything, you book things as soon as you decide. This reduces stress and ensures everything is done on time.
A Nigerian e-commerce company adopted Continuous Delivery. They used to release updates once a month. Now they release updates multiple times a week. New features reach customers faster, and their sales have increased.
THE BENEFITS OF CD
+--------------------------------------------------+
| |
| 🚀 FASTER RELEASES |
| New features reach users quickly |
| |
| 🛡️ LESS RISK |
| Small releases are safer |
| |
| 🔧 QUICK FIXES |
| Bugs are fixed in minutes |
| |
| 😊 HAPPY USERS |
| Users get new features fast |
| |
| 🧘 LESS STRESS |
| No more stressful release days |
| |
| 📈 BETTER QUALITY |
| Faster feedback means better software |
| |
| 💪 TEAM CONFIDENCE |
| Teams can release anytime |
| |
| ALL BECAUSE OF CD! 🎉 |
| |
+--------------------------------------------------+
CD has many benefits. It leads to faster releases, less risk, quick fixes, happy users, less stress, better quality, and team confidence.
CD and DevOps: CD is a core part of DevOps. Together with CI, it forms the automation backbone of DevOps. CD helps teams deliver software continuously and reliably.
CD and DevOps work together to help teams deliver software faster and better. CD provides the automation for releasing software, and DevOps provides the culture and processes.
Imagine DevOps is a car. CI is the engine that builds and tests the code. CD is the wheels that deliver the code to users. Without CD, the car would not go anywhere. With CD, the car moves smoothly and quickly.
A company uses DevOps practices including CI and CD. Their developers push code frequently. CI builds and tests it. CD delivers it to users. Together, they deliver software fast and reliably.
Your school has a system for managing projects. CI is like the quality check. CD is like the delivery system. DevOps is the whole system including planning, execution, delivery, and review.
Your family has a system for managing the household. CI is like checking the plan. CD is like executing the plan. DevOps is the whole system including planning, execution, and improvement.
A Nigerian company uses DevOps and CD. CD is the delivery engine of their DevOps pipeline. Without CD, their DevOps would be incomplete. Together, they deliver great software.
CD AND DEVOPS
+--------------------------------------------------+
| |
| DEVOPS = CULTURE + TOOLS + PROCESSES |
| +-------------------------------------------+ |
| | 📋 Plan | |
| | 💻 Code | |
| | 🏗️ Build ← CI is here! | |
| | ✅ Test ← CI is here! | |
| | 🚀 Release ← CD is here! | |
| | 🔄 Deploy ← CD is here! | |
| | 📊 Operate | |
| | 👀 Monitor | |
| +-------------------------------------------+ |
| | |
| V |
| CD IS A CORE PART OF DEVOPS |
| +-------------------------------------------+ |
| | ✅ CD automates release and deployment | |
| | ✅ CD gives fast feedback to users | |
| | ✅ CD helps maintain quality | |
| +-------------------------------------------+ |
| |
| 🔑 CD + DevOps = Powerful software delivery! |
| |
+--------------------------------------------------+
CD is a core part of DevOps. It provides the automation for releasing and deploying software. Together with CI, CD helps teams deliver software fast and reliably.
In this lesson, we will review everything we have learned about Continuous Delivery and Deployment. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use CI/CD every day. They push code, CI builds and tests it, CD deploys it. Their software is always up to date and customers are happy.
Your class has learned about CD. They understand the importance of delivering work quickly and safely.
Your family has learned about CD. They understand the importance of planning and delivering things efficiently.
A Nigerian developer has learned all these CD concepts. They can now set up CI/CD for their team and help their company deliver better software faster.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 Continuous Delivery = Always ready to release |
| 📌 Continuous Deployment = Automatically release |
| 📌 CI/CD pipeline = Full automation flow |
| 📌 Deployment strategies = Safe release plans |
| 📌 Artifact management = Versioned packages |
| 📌 Release governance = Rules and approvals |
| 📌 Benefits: faster, safer, happier |
| 📌 CD is a core part of DevOps |
| |
| YOU ARE NOW A CD BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about Continuous Delivery and Deployment. CD helps teams release software quickly and safely. It is a core part of DevOps.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Continuous Delivery (CD) | A practice where software is always ready to be released |
| Continuous Deployment | A practice where software is automatically released to users |
| CI/CD Pipeline | The complete series of steps from writing code to releasing it |
| Deployment Strategy | A plan for releasing software safely |
| Rolling Update | Updating servers one at a time |
| Blue-Green Deployment | Switching from old to new version at once |
| Canary Release | Releasing to a small group of users first |
| Artifact | The packaged version of code ready for deployment |
| Artifact Management | Storing and versioning packaged code |
| Release Governance | Rules and approvals before a release |
| Rollback | Going back to an older version |
| Production | The live environment where users access the software |
| Staging | A test environment that mimics production |
| Monitor | Watching the software for problems |
| CI/CD | The combination of CI, CD, and Continuous Deployment |
Here are the most important concepts from this module. These are the big ideas that will help you understand Continuous Delivery and Deployment.
CD makes software always ready to release. Continuous Delivery ensures that every change that passes tests is prepared for release. This means you can release anytime.
Continuous Deployment releases automatically. Continuous Deployment takes it a step further by automatically releasing to users. No human approval needed.
The CI/CD pipeline automates everything. From writing code to releasing it, the CI/CD pipeline is fully automated. This saves time and reduces errors.
Deployment strategies keep releases safe. Strategies like rolling updates, blue-green, and canary releases help teams release software safely.
Artifacts are versioned packages. Artifacts are the packaged code that gets deployed. Managing them well means you can deploy any version anytime.
Release governance ensures quality. Rules and approvals before release make sure releases are safe and compliant.
CD is a core part of DevOps. CD provides the automation for releasing software. Together with CI, it forms the CI/CD backbone of DevOps.
Let us look at how to set up a CI/CD pipeline in simple steps:
Decide which CI/CD tools to use. GitHub Actions, GitLab CI, and Jenkins are all good choices. Choose the one that works best for your team.
First, set up Continuous Integration. This automatically builds and tests your code every time it is pushed.
Set up a place to store your artifacts. This could be a package registry like JFrog Artifactory, GitHub Packages, or GitLab's package registry.
Set up Continuous Delivery. Configure your pipeline to automatically package code into artifacts and make them ready for release.
Add deployment to your pipeline. This could be Continuous Deployment (automatic) or require a manual approval step.
Decide how you will deploy. Rolling updates, blue-green, or canary releases are common choices.
Add monitoring to your pipeline. Watch the deployed software for any problems. If something goes wrong, you can roll back.
STEP-BY-STEP: SETTING UP CI/CD
Step 1: CHOOSE TOOLS
+-------------------+
| GitHub Actions, |
| GitLab CI, |
| Jenkins |
+-------------------+
|
V
Step 2: SET UP CI
+-------------------+
| Build and test |
| automatically |
+-------------------+
|
V
Step 3: ADD ARTIFACT STORAGE
+-------------------+
| Store packaged |
| code |
+-------------------+
|
V
Step 4: SET UP CD
+-------------------+
| Prepare code |
| for release |
+-------------------+
|
V
Step 5: ADD DEPLOYMENT
+-------------------+
| Deploy to |
| servers |
+-------------------+
|
V
Step 6: CHOOSE STRATEGY
+-------------------+
| Rolling, Blue- |
| Green, Canary |
+-------------------+
|
V
Step 7: ADD MONITORING
+-------------------+
| Watch for |
| problems |
+-------------------+
An e-commerce company uses a CI/CD pipeline on GitHub Actions. Every time code is pushed, the pipeline builds, tests, and deploys to staging. After approval, it deploys to production using a blue-green deployment. The whole process takes 20 minutes.
A mobile app team uses Continuous Deployment. Every time a developer fixes a bug or adds a feature, the app is automatically built, tested, and submitted to the app store. Users get updates daily.
A bank uses Continuous Delivery but not Continuous Deployment. They use CI/CD to prepare releases, but every release must be approved by the security team and a senior manager before deployment.
Flutterwave uses a CI/CD pipeline to release their payment platform. They use canary releases to test new features with a small group of users before rolling out to everyone.
Paystack uses GitHub Actions for their CI/CD pipeline. Every change is automatically built, tested, and deployed to staging. After testing, it is deployed to production using a blue-green deployment strategy.
A Nigerian tech startup uses Continuous Deployment for their website. Every time a developer pushes code that passes all tests, it is automatically deployed to production. This means they can release new features several times a day.
You have a lemonade stand. Every time you make a new batch of lemonade, you automatically put it in a pitcher and put it on the counter for customers. Continuous Deployment is like automatically putting the lemonade on the counter as soon as it is made.
You are wrapping birthday gifts. Instead of waiting until the party to give them, you give them as soon as they are wrapped. Continuous Deployment is like giving gifts as soon as they are wrapped.
You are doing homework. Every time you finish a question, you submit it automatically. Your teacher gets each question as soon as it is done. Continuous Deployment is like submitting homework question by question.
Your family uses a shared shopping list. Every time someone adds an item, the list automatically updates on everyone's phones. This is like Continuous Deployment.
Your family uses a shared calendar. Every time someone adds an event, it automatically appears on everyone's calendar. This is like Continuous Deployment.
Your family has a shared photo album. Every time someone adds a photo, it automatically appears in the album for everyone to see. This is like Continuous Deployment.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about Continuous Delivery and Deployment. Here are some tips to support their learning:
Mistake 1: Deploying without testing.
Always test before deploying. Deploying without testing can break the system for all users. CI should catch these problems.
Mistake 2: Not having a rollback plan.
Always have a plan to go back to the previous version if something goes wrong. A good CI/CD pipeline includes rollback capability.
Mistake 3: Deploying during peak hours.
Deploy during low-traffic times if possible. This reduces the impact if something goes wrong.
Mistake 4: Not monitoring after deployment.
Always monitor after deployment. Watch for errors, slow performance, or other problems.
Mistake 5: Skipping governance.
Release governance is important for safety. Do not skip approvals and compliance checks.
Mistake 6: Using Continuous Deployment for critical systems without testing.
For critical systems (banking, healthcare), use Continuous Delivery with approvals instead of Continuous Deployment.
Test everything before deployment.
Make sure all tests pass before deploying. This includes unit tests, integration tests, and end-to-end tests.
Always have a rollback plan.
Be able to go back to the previous version within minutes if something goes wrong.
Use a deployment strategy.
Choose a strategy that fits your needs. Rolling updates for general use, blue-green for zero downtime, canary for testing with real users.
Monitor after deployment.
Watch your logs, metrics, and user feedback after deployment. This helps you catch problems quickly.
Start small.
If you are new to CD, start with a simple project. Learn from that experience and then expand.
Use artifacts.
Always store versioned artifacts. This lets you deploy any version anytime.
Keep governance lightweight.
Have governance, but keep it lightweight. Too many approvals can slow down releases.
THE CI/CD PIPELINE
+--------------------------------------------------+
| |
| CODE |
| +-------------------------------------------+ |
| | Developer writes and pushes code | |
| +-------------------------------------------+ |
| | |
| V |
| BUILD |
| +-------------------------------------------+ |
| | Code is compiled or built | |
| +-------------------------------------------+ |
| | |
| V |
| TEST |
| +-------------------------------------------+ |
| | Automated tests run | |
| +-------------------------------------------+ |
| | |
| V |
| PACKAGE |
| +-------------------------------------------+ |
| | Code is packaged (artifact) | |
| +-------------------------------------------+ |
| | |
| V |
| RELEASE |
| +-------------------------------------------+ |
| | Code is prepared for release | |
| +-------------------------------------------+ |
| | |
| V |
| DEPLOY |
| +-------------------------------------------+ |
| | Code is deployed to servers | |
| +-------------------------------------------+ |
| | |
| V |
| MONITOR |
| +-------------------------------------------+ |
| | Code is monitored for problems | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
DEPLOYMENT STRATEGIES
ROLLING UPDATE:
+--------------------------------------------------+
| Server 1: Old → New |
| Server 2: Old → New |
| Server 3: Old → New |
| (One at a time) |
+--------------------------------------------------+
BLUE-GREEN:
+--------------------------------------------------+
| Blue (Live): Old version |
| Green (New): New version |
| Switch users from Blue to Green instantly! |
+--------------------------------------------------+
CANARY:
+--------------------------------------------------+
| 1% Users → New version |
| ✅ If good → 10% Users |
| ✅ If good → 50% Users |
| ✅ If good → 100% Users |
+--------------------------------------------------+
CI VS CD VS CONTINUOUS DEPLOYMENT
CI:
+--------------------------------------------------+
| Build + Test automatically |
| "Does it work?" |
+--------------------------------------------------+
CD (Continuous Delivery):
+--------------------------------------------------+
| Build + Test + Package automatically |
| "Ready to release!" |
| Human decides when to release |
+--------------------------------------------------+
Continuous Deployment:
+--------------------------------------------------+
| Build + Test + Package + Deploy automatically |
| "Released to users!" |
| No human needed! |
+--------------------------------------------------+
| Aspect | Continuous Delivery | Continuous Deployment |
|---|---|---|
| Automation | Build, test, package | Build, test, package, deploy |
| Human Approval | Yes (decides when to release) | No (releases automatically) |
| Release Speed | Fast (when approved) | Very fast (immediate) |
| Risk | Low (human oversight) | Low (with good testing) |
| Best For | Critical systems (banking, healthcare) | Low-risk systems (websites, apps) |
| Strategy | Risk | Downtime | Best For |
|---|---|---|---|
| Rolling Update | Low | None | General use |
| Blue-Green | Low | None | Zero downtime required |
| Canary | Very low | None | Testing with real users |
| Stage | Purpose | Automated? |
|---|---|---|
| Code | Write and push code | No (developer does it) |
| Build | Compile or build the code | Yes |
| Test | Run automated tests | Yes |
| Package | Package for release (artifact) | Yes |
| Release | Prepare for release (with approval) | Partially (approval is manual) |
| Deploy | Deploy to servers | Yes |
| Monitor | Watch for problems | Yes |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 4 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Continuous Delivery (CD) is a practice where software is always ready to be released. Every change that passes all tests is automatically prepared for release. A human decides when to actually release it.
Continuous Deployment is a practice where every change that passes all tests is automatically released to users. No human approval is needed.
The CI/CD pipeline is the complete series of steps from writing code to releasing it to users. It combines CI, CD, and monitoring into one automated flow.
Deployment strategies are plans for releasing software safely. Common strategies include rolling updates (one server at a time), blue-green deployments (switching versions), and canary releases (small groups first).
Artifacts are packaged versions of code ready for deployment. Artifact management is the practice of storing and versioning these packages.
Release governance is the set of rules and approvals that must be followed before a release. It ensures releases are safe and compliant.
CD leads to faster releases, less risk, quick fixes, happy users, less stress, better quality, and team confidence. It is a core part of DevOps.
You have now completed Module 4! You are ready to move on to Module 5, where you will learn about Infrastructure as Code (IaC). Keep up the great work!
Q1: What is Continuous Delivery?
A: Continuous Delivery is a practice where software is always ready to be released. Every change is automatically prepared for release, but a human decides when to release it.
Q2: What is Continuous Deployment?
A: Continuous Deployment is a practice where every change that passes all tests is automatically released to users. No human approval is needed.
Q3: What is the difference between Continuous Delivery and Continuous Deployment?
A: Continuous Delivery has human approval before release. Continuous Deployment does not — it is fully automatic.
Q4: What is a CI/CD pipeline?
A: A CI/CD pipeline is the complete series of steps from writing code to releasing it to users. It combines CI, CD, and monitoring into one automated flow.
Q5: What is a deployment strategy?
A: A deployment strategy is a plan for how software is released to users. It helps teams release software safely.
Q6: What is blue-green deployment?
A: Blue-green deployment is a strategy where you have two identical environments. You deploy the new version to the "green" environment, test it, and then switch users from "blue" to "green."
Q7: What is an artifact?
A: An artifact is the packaged version of your code that is ready to be deployed. It is like the final product of the build process.
Q8: What is release governance?
A: Release governance is the set of rules and approvals that must be followed before a release. It ensures releases are safe and compliant.
Q9: What are the benefits of CD?
A: CD leads to faster releases, less risk, quick fixes, happy users, less stress, better quality, and team confidence.
Q10: Is CD used in Nigeria?
A: Yes, many Nigerian companies use CD. It is helping them deliver software faster and compete globally.
What is Continuous Delivery?
Answer: Continuous Delivery is a practice where software is always ready to be released. A human decides when to release it.
What is Continuous Deployment?
Answer: Continuous Deployment is a practice where every change that passes tests is automatically released to users.
What is the difference between Continuous Delivery and Continuous Deployment?
Answer: Continuous Delivery requires human approval. Continuous Deployment is fully automatic.
What is the CI/CD pipeline?
Answer: The complete series of steps from writing code to releasing it to users.
Name three deployment strategies.
Answer: Rolling update, blue-green deployment, and canary release.
What is a rolling update?
Answer: Updating servers one at a time.
What is blue-green deployment?
Answer: Switching from the old version to the new version at once using two environments.
What is a canary release?
Answer: Releasing to a small group of users first, then gradually to everyone.
What is an artifact?
Answer: The packaged version of code ready for deployment.
What is artifact management?
Answer: Storing and versioning packaged code for deployment.
What is release governance?
Answer: Rules and approvals that must be followed before a release.
Name two benefits of CD.
Answer: Faster releases and less risk. (Other answers: quick fixes, happy users, less stress, better quality, team confidence.)
Is CD part of DevOps?
Answer: Yes, CD is a core part of DevOps.
What is a rollback?
Answer: Going back to an older version if something goes wrong.
Is CD used in Nigeria?
Answer: Yes, many Nigerian companies use CD.
Fill in the blanks with the correct words from the list:
Word list: Continuous Delivery, Continuous Deployment, pipeline, rolling update, blue-green, canary, artifact, governance, rollback, DevOps, artifact management
__________ is a practice where software is always ready to be released.
Answer: Continuous Delivery
__________ is a practice where software is automatically released to users.
Answer: Continuous Deployment
The CI/CD __________ is the complete series of steps from writing code to releasing it.
Answer: pipeline
A __________ updates servers one at a time.
Answer: rolling update
__________ deployment switches from the old version to the new version at once.
Answer: blue-green
A __________ release deploys to a small group of users first.
Answer: canary
An __________ is the packaged version of code ready for deployment.
Answer: artifact
__________ is the practice of storing and versioning packaged code.
Answer: artifact management
Release __________ is the set of rules and approvals before a release.
Answer: governance
A __________ is going back to an older version if something goes wrong.
Answer: rollback
CD is a core part of __________.
Answer: DevOps
Write True or False for each statement:
Continuous Delivery requires human approval before release.
Answer: True
Continuous Deployment requires human approval before release.
Answer: False (Continuous Deployment is fully automatic)
The CI/CD pipeline includes monitoring.
Answer: True
A rolling update deploys to all servers at the same time.
Answer: False (It updates one server at a time)
Blue-green deployment uses two identical environments.
Answer: True
A canary release tests with all users at once.
Answer: False (It tests with a small group first)
An artifact is the packaged version of code ready for deployment.
Answer: True
Artifact management is not important in CD.
Answer: False (It is very important)
Release governance ensures releases are safe and compliant.
Answer: True
CD leads to slower releases.
Answer: False (CD leads to faster releases)
CD is a core part of DevOps.
Answer: True
A rollback means going back to an older version.
Answer: True
CD is not used in Nigeria.
Answer: False
Continuous Deployment is riskier than Continuous Delivery.
Answer: True (without proper testing)
Monitoring is optional in CI/CD pipelines.
Answer: False (It is essential)
Choose the correct answer for each question:
What is Continuous Delivery?
A) Software is automatically released to users
B) Software is always ready to be released
C) Software is never released
D) Software is released once a year
Answer: B
What is Continuous Deployment?
A) Software is automatically released to users
B) Software is always ready to be released
C) Software is never released
D) Software is released once a year
Answer: A
What is the difference between Continuous Delivery and Continuous Deployment?
A) Continuous Delivery is faster
B) Continuous Delivery has human approval; Continuous Deployment
does not
C) There is no difference
D) Continuous Deployment is slower
Answer: B
What is the CI/CD pipeline?
A) A series of steps from code to release
B) A type of computer
C) A programming language
D) A video game
Answer: A
Which deployment strategy updates servers one at a time?
A) Blue-green
B) Canary
C) Rolling update
D) Big bang
Answer: C
Which deployment strategy uses two identical environments?
A) Blue-green
B) Canary
C) Rolling update
D) Big bang
Answer: A
Which deployment strategy tests with a small group of users first?
A) Blue-green
B) Canary
C) Rolling update
D) Big bang
Answer: B
What is an artifact?
A) A type of computer
B) A packaged version of code ready for deployment
C) A deployment strategy
D) A programming language
Answer: B
What is release governance?
A) A type of computer
B) Rules and approvals before a release
C) A deployment strategy
D) A programming language
Answer: B
What is a rollback?
A) Going back to an older version
B) Releasing a new version
C) Testing a new version
D) Deleting a version
Answer: A
Which is a benefit of CD?
A) Slower releases
B) More bugs
C) Faster releases
D) Unhappy users
Answer: C
Is CD part of DevOps?
A) No
B) Yes, it is a core part
C) Sometimes
D) Only for large companies
Answer: B
What should you do after deployment?
A) Ignore the system
B) Monitor for problems
C) Delete the system
D) Go home
Answer: B
Is CD used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
What is the purpose of artifact management?
A) To delete artifacts
B) To store and version packaged code
C) To write code
D) To deploy code
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Continuous Delivery | A. Automatically releases software to users |
| 2. Continuous Deployment | B. Software is always ready to be released |
| 3. Rolling Update | C. Switching from old to new version at once |
| 4. Blue-Green | D. Updating servers one at a time |
| 5. Canary Release | E. The packaged version of code ready for deployment |
| 6. Artifact | F. Rules and approvals before a release |
| 7. Release Governance | G. Releasing to a small group of users first |
| 8. Rollback | H. Going back to an older version |
| 9. CI/CD Pipeline | I. The complete series of steps from code to release |
| 10. Artifact Management | J. Storing and versioning packaged code |
Answers:
What is Continuous Delivery and why is it useful?
Answer: Continuous Delivery is a practice where software is always ready to be released. It is useful because it makes releasing software easy and safe. You can release anytime you want without spending days preparing.
Explain the difference between Continuous Delivery and Continuous Deployment.
Answer: Continuous Delivery requires human approval before release. The software is always ready, but a human decides when to release it. Continuous Deployment is fully automatic — every change that passes tests is automatically released to users.
Describe three deployment strategies.
Answer:
What is artifact management and why is it important?
Answer: Artifact management is the practice of storing and versioning packaged code (artifacts). It is important because it lets you deploy any version anytime. If a new version has a problem, you can quickly roll back to a previous version.
How does CD support DevOps?
Answer: CD is a core part of DevOps. It provides the automation for releasing and deploying software. CD gives fast feedback to users, helps maintain quality, and supports the continuous flow of value to customers. Together with CI, CD forms the automation backbone of DevOps.
A company takes 3 months to release each new version of their software. They spend most of that time preparing for the release. They want to release faster.
Question: How could CD help this company?
Answer: CD could help by making the software always ready to release. With CD, they would not need to spend weeks preparing for each release. They could release anytime. They could use Continuous Delivery to keep code ready and release weekly instead of every 3 months.
A company had a big release that broke the system for all users. It took hours to fix. They want to avoid this in the future.
Question: What deployment strategy could help them?
Answer: A canary release strategy could help. They would release to a small group of users first (like 1%). If there are no problems, they would gradually increase the percentage to 10%, 50%, and finally 100%. This way, if something goes wrong, only a few users are affected and they can fix it quickly.
A Nigerian startup has built a new app. They want to release updates daily but are worried about breaking things. They are using CI but have not set up CD yet.
Question: What should the startup do to implement CD?
Answer: The startup should start with Continuous Delivery. They would set up a CI/CD pipeline that builds, tests, and packages the code. They could use a canary release strategy to test with a small group of users first. After they are comfortable, they could move to Continuous Deployment for less risky parts of the app.
Instructions:
Instructions:
Why do you think releasing software frequently is better than releasing rarely?
Discuss with your classmates and share your ideas.
Have you ever experienced a problem after an update? How did it make you feel?
Share your experiences and thoughts.
What are some other situations where automatic delivery is helpful?
Think about school, home, and other activities.
Do you think Continuous Deployment is always better than Continuous Delivery? Why or why not?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from CD?
Share examples of companies in Nigeria.
What do you think is the most important part of the CI/CD pipeline?
Explain why you think so.
Do you think CD is easy to implement? Why or why not?
Share your thoughts.
What is the most important thing you learned about CD today?
Share with the class.
Goal: Create a simple guide to teach beginners about Continuous Delivery and Deployment.
Instructions:
Goal: Learn about real-world CI/CD practice.
Instructions:
Scenario:
You are a CD architect at a Nigerian company. The company builds a mobile app for banking. They have 15 developers. They want to release new features faster but are worried about breaking things.
The company has:
Challenge: Create a complete CD implementation plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 4: "Continuous Delivery & Deployment (CD)." You now understand how CD helps teams release software quickly, safely, and automatically.
In Module 5, you will learn:
Before you start Module 5, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 5! 🚀
© 2026 Certified DevOps Engineer Course • Module 4: Continuous Delivery & Deployment (CD)
Welcome to Module 5 of our Certified DevOps Engineer course! This module is called "Infrastructure as Code (IaC): Managing Infrastructure Like Software."
In this module, we will learn about Infrastructure as Code (IaC) — a practice where we manage servers, networks, and other infrastructure using code instead of manual processes. It is like writing instructions for a robot to build your infrastructure for you!
Think of IaC like having a magical recipe book. Instead of building things by hand every time, you write down the recipe. Then, whenever you need to build something, you just follow the recipe. The result is always exactly the same, every time!
Hello and welcome back! In Module 1, we learned about DevOps. In Module 2, we learned about Git. In Module 3, we learned about Continuous Integration. In Module 4, we learned about Continuous Delivery and Deployment. Now, in Module 5, we are going to learn about Infrastructure as Code (IaC).
Imagine you are building a LEGO castle. You build it once, and it is amazing. But then you need to build it again in a different place. You have to remember all the steps. You might forget some pieces. The second castle might not look exactly the same.
Now imagine you have a set of instructions that tell you exactly how to build the castle. Every time you follow the instructions, the castle looks exactly the same. That is what Infrastructure as Code does for servers and networks!
In this module, we will learn all about IaC — what it is, why it is important, how it works, and what tools teams use to implement it. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover how teams manage infrastructure with code!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company called "TechBuild Solutions." They built websites and apps for other companies. Every time they got a new customer, they had to set up servers, install software, and configure networks.
The problem was that every setup was done manually. A person would sit at a computer and type commands, click buttons, and configure everything by hand. This took a long time. Sometimes they made mistakes. Different people set things up differently. It was like building a LEGO castle without instructions — every castle looked a little bit different.
One day, a clever engineer named Mr. Ade had an idea. He said, "What if we write down all the steps for setting up a server? What if we save it in a file and run it whenever we need a new server?"
Mr. Ade created a magic recipe book — a set of files that described exactly how to set up a server. When they needed a new server, they just ran the recipe. The computer would read the instructions and set everything up automatically.
Now, every server was exactly the same. Setting up a new server took minutes instead of hours. They never made mistakes. TechBuild Solutions grew and became one of the most successful companies in Nigeria.
This story shows us how powerful it is to manage infrastructure with code. That is exactly what Infrastructure as Code (IaC) does! Let us learn more.
Infrastructure as Code (IaC) is a practice where you manage your servers, networks, and other infrastructure using code instead of manual processes. You write instructions in a file, and a computer follows those instructions to build your infrastructure.
IaC is important because it makes infrastructure setup fast, consistent, and repeatable. Instead of doing things by hand, you automate everything. This saves time, reduces mistakes, and makes everything predictable.
Imagine you are baking a cake. You have two ways to do it:
IaC is like having a written recipe for your infrastructure!
A company uses IaC to set up their servers. They have a file that describes exactly what each server should look like. When they need a new server, they run the file, and the server is created automatically.
Your class has a science experiment. The teacher gives you written instructions. Every time you do the experiment, you follow the instructions and get the same result. IaC is like having those written instructions.
Your family has a recipe for your favorite meal. Every time you cook it, you follow the recipe and it tastes great. IaC is like that recipe but for servers.
A Nigerian company uses IaC to set up their cloud infrastructure. They have code that creates servers, databases, and networks automatically. They can set up a complete environment in minutes.
INFRASTRUCTURE AS CODE (IaC)
MANUAL WAY:
+--------------------------------------------------+
| Person types commands |
| Person configures servers |
| Person installs software |
| Slow, error-prone, inconsistent |
+--------------------------------------------------+
IaC WAY:
+--------------------------------------------------+
| Code File (Recipe) |
| +-------------------------------------------+ |
| | server { | |
| | type = "web" | |
| | size = "medium" | |
| | software = ["nginx", "php"] | |
| | } | |
| +-------------------------------------------+ |
| | |
| V |
| Computer reads code and builds infrastructure |
| +-------------------------------------------+ |
| | Fast, consistent, repeatable | |
| +-------------------------------------------+ |
| |
| 🔑 IaC = Infrastructure managed like software! |
| |
+--------------------------------------------------+
Infrastructure as Code (IaC) is a practice where you manage infrastructure using code. It makes setup fast, consistent, and repeatable. It is like having a recipe for your servers.
Why we need IaC: We need IaC because the manual way of managing infrastructure has many problems. It is slow, error-prone, and inconsistent. IaC solves all these problems.
Understanding why we need IaC helps us appreciate how much better it is to manage infrastructure with code. It shows us the problems that IaC solves.
Imagine you are trying to build a treehouse. You have two ways:
IaC is like having those instructions!
| Problem | What It Means | IaC Solution |
|---|---|---|
| Slow Setup | Setting up servers takes hours or days | IaC does it in minutes |
| Human Errors | People make mistakes when typing commands | Code is consistent and error-free |
| Inconsistency | Servers are set up differently each time | Every server is exactly the same |
| Hard to Reproduce | If a server breaks, it is hard to rebuild it | Run the code and rebuild instantly |
| No History | No one knows what changes were made | Changes are tracked in code (Git) |
A company used to take 3 days to set up a new server. They made mistakes all the time. After adopting IaC, they set up a server in 5 minutes with no mistakes.
Your class is doing a group project. Without a plan, everyone does things differently. With a plan (like IaC), everyone follows the same instructions and the project is consistent.
Your family is planning a party. Without a checklist, you might forget something. With a checklist (like IaC), you do everything correctly every time.
A Nigerian company used to spend days setting up infrastructure for new clients. With IaC, they now do it in minutes. They can serve more clients and grow faster.
WHY WE NEED IAC
WITHOUT IAC:
+--------------------------------------------------+
| ❌ Slow setup (hours or days) |
| ❌ Human errors |
| ❌ Inconsistent servers |
| ❌ Hard to reproduce |
| ❌ No history of changes |
+--------------------------------------------------+
WITH IAC:
+--------------------------------------------------+
| ✅ Fast setup (minutes) |
| ✅ No human errors |
| ✅ Consistent servers |
| ✅ Easy to reproduce |
| ✅ Full history of changes |
+--------------------------------------------------+
We need IaC because manual infrastructure management is slow, error-prone, and inconsistent. IaC solves all these problems by automating everything with code.
Declarative and Imperative are two ways of writing IaC code. They describe how you tell the computer what to do.
Understanding the difference helps you choose the right approach for your project. Each approach has its own strengths and weaknesses.
Imagine you are ordering food at a restaurant:
| Aspect | Declarative | Imperative |
|---|---|---|
| What You Do | Say what you want, not how to do it | Say exactly how to do it |
| Example | "I want a server with 4GB RAM and Ubuntu." | "Install Ubuntu, create a user, set up networking..." |
| Focus | On the final result (what) | On the steps (how) |
| Complexity | Easier to read and understand | More detailed and complex |
| Tools | Terraform, CloudFormation | Ansible (can be both), scripts |
A company uses Terraform (declarative) to set up servers. They write: "I want 3 web servers, 2 databases, and 1 load balancer." Terraform figures out the steps to make it happen.
Your teacher gives you a project. Declarative is like the teacher saying "I want a report on the environment" without telling you how to write it. Imperative is like the teacher saying "Write an introduction, then three paragraphs, then a conclusion."
Your parents say "Please clean the living room." That is declarative. They do not tell you exactly how to clean it. They just want it clean.
A Nigerian company uses Terraform (declarative) for their infrastructure. They describe what they want, and Terraform makes it happen. This is simpler and easier to maintain.
DECLARATIVE VS IMPERATIVE
DECLARATIVE (What):
+--------------------------------------------------+
| "I want a server with: |
| - 4GB RAM |
| - Ubuntu OS |
| - Nginx installed" |
| |
| ✅ Focus on the final result |
| ✅ Easier to read and understand |
+--------------------------------------------------+
IMPERATIVE (How):
+--------------------------------------------------+
| Step 1: Download Ubuntu |
| Step 2: Install Ubuntu |
| Step 3: Install Nginx |
| Step 4: Configure Nginx |
| Step 5: Start Nginx |
| |
| ✅ Gives exact instructions |
| ✅ More control |
+--------------------------------------------------+
Declarative says what you want; Imperative says how to do it. Declarative is easier to read and maintain. Imperative gives more control.
Immutable infrastructure means that infrastructure is never changed after it is created. Instead of making changes to a server, you create a new server with the changes and replace the old one.
Immutable infrastructure is important because it prevents "configuration drift." When you make changes to a server over time, it becomes different from other servers. Immutable infrastructure keeps everything exactly the same.
Imagine you have a toy car. Instead of fixing it when it breaks, you build a new one and throw the old one away. You never change the car — you always start fresh. Immutable infrastructure is like that for servers!
| Aspect | Mutable Infrastructure | Immutable Infrastructure |
|---|---|---|
| Changes | Changes are made to existing servers | New servers are created for changes |
| Consistency | Servers drift apart over time | Servers are always identical |
| Fixing Problems | Fix the problem on the server | Create a new server and replace it |
| Risk | Changes can break things | Always start from a known good state |
| Example | Updating a server with new software | Creating a new server with the new software |
A company uses immutable infrastructure. When they need to update software, they create a new server with the updated software, test it, and then switch traffic to the new server. The old server is turned off.
Instead of fixing a broken pencil, you get a new one. Immutable infrastructure is like getting a new pencil instead of fixing the old one.
Instead of trying to fix a broken plate, you buy a new one. Immutable infrastructure is like buying a new plate instead of fixing the broken one.
A Nigerian company uses immutable infrastructure. When they need to update their website, they create new servers with the new code, test them, and switch traffic. This makes their website very reliable.
IMMUTABLE INFRASTRUCTURE
MUTABLE (Changes on existing server):
+--------------------------------------------------+
| Server 1: Original |
| Update → Server 1: Changed |
| Update → Server 1: Changed again |
| Result: Server is different from others |
+--------------------------------------------------+
IMMUTABLE (Create new server for changes):
+--------------------------------------------------+
| Server 1: Original |
| Update → Create Server 2: Changed |
| Update → Create Server 3: Changed again |
| Result: All servers are identical |
+--------------------------------------------------+
🔑 Immutable = Never change, always replace!
Immutable infrastructure means never changing servers after they are created. Instead, you create new servers with changes and replace the old ones. This keeps everything consistent and reliable.
Terraform is a popular IaC tool created by HashiCorp. It lets you define your infrastructure in code and create, update, and delete it automatically. Terraform is declarative — you say what you want, and Terraform figures out how to do it.
Terraform is important because it works with almost any cloud provider (AWS, Azure, Google Cloud) and many other services. It is one of the most popular IaC tools in the world.
Imagine Terraform as a magical building machine. You give it a blueprint (your code), and it builds exactly what you asked for. If you change the blueprint, Terraform figures out what changed and updates only those parts.
A company uses Terraform to manage their AWS infrastructure. They have a file that describes their servers, databases, and networks. When they need to make a change, they update the file and run Terraform. Terraform makes the changes automatically.
Your class has a robot that builds dioramas. You give the robot a drawing of what you want, and it builds it. Terraform is like that robot but for servers.
You have a 3D printer. You give it a design file, and it prints the object. Terraform is like a 3D printer for infrastructure.
A Nigerian company uses Terraform to manage their cloud infrastructure on AWS. They have all their infrastructure defined in code. They can create, update, and delete infrastructure with a single command.
TERRAFORM
+--------------------------------------------------+
| Terraform Code (main.tf) |
| +-------------------------------------------+ |
| | resource "aws_instance" "web" { | |
| | ami = "ami-12345" | |
| | instance_type = "t2.micro" | |
| | } | |
| +-------------------------------------------+ |
| | |
| V |
| Terraform Commands: |
| +-------------------------------------------+ |
| | terraform init → Sets up Terraform | |
| | terraform plan → Shows what will change | |
| | terraform apply → Creates infrastructure| |
| | terraform destroy → Deletes infrastructure| |
| +-------------------------------------------+ |
| | |
| V |
| Infrastructure Created! |
| +-------------------------------------------+ |
| | ☁️ AWS: 1 web server running! | |
| +-------------------------------------------+ |
| |
| 🔑 Terraform = Infrastructure as Code tool! |
| |
+--------------------------------------------------+
Terraform is a popular IaC tool that lets you define infrastructure in code. It is declarative, works with multiple clouds, and has commands to plan, apply, and destroy infrastructure.
Terraform state is a file that keeps track of all the infrastructure Terraform has created. It is like a map that tells Terraform what resources exist.
State is important because Terraform needs to know what it has created. Without state, Terraform would not know what to update or delete. State makes Terraform smart and efficient.
Imagine you are building a LEGO castle. You have a list of all the pieces you used. When you want to change something, you look at the list to know what to change. Terraform state is like that list for your infrastructure.
| Option | Description | Best For |
|---|---|---|
| Local State | State is stored on your computer | Learning and testing |
| Remote State | State is stored in the cloud (S3, Azure Storage, etc.) | Teams and production |
| State Locking | Prevents two people from changing state at the same time | Teams working together |
A company stores their Terraform state in an AWS S3 bucket. This way, all team members can access the state. They also use state locking so two people do not make changes at the same time.
Your class has a shared project folder. Everyone can see it, and only one person can edit at a time. Terraform state is like that shared folder.
Your family has a shared shopping list. Everyone can see it, and only one person can add to it at a time. Terraform state is like that shopping list.
A Nigerian company stores their Terraform state in the cloud. This means their team in Lagos and their team in Abuja can both work on the same infrastructure. State locking prevents conflicts.
TERRAFORM STATE
+--------------------------------------------------+
| TERRAFORM STATE FILE |
| +-------------------------------------------+ |
| | { | |
| | "resources": [ | |
| | { | |
| | "type": "aws_instance", | |
| | "id": "i-12345", | |
| | "name": "web-server" | |
| | } | |
| | ] | |
| | } | |
| +-------------------------------------------+ |
| |
| Local State: |
| +-------------------------------------------+ |
| | Stored on your computer | |
| | Good for learning | |
| +-------------------------------------------+ |
| |
| Remote State: |
| +-------------------------------------------+ |
| | Stored in the cloud (S3, Azure) | |
| | Shared by team | |
| | State locking prevents conflicts | |
| +-------------------------------------------+ |
| |
| 🔑 State is Terraform's memory! |
| |
+--------------------------------------------------+
Terraform state is a file that keeps track of what Terraform has created. It can be stored locally or remotely. Remote state is best for teams.
Configuration Management is the practice of managing the configuration of servers and software. Ansible is a popular tool for configuration management that is simple and powerful.
Configuration management is important because it ensures that all servers are configured correctly and consistently. Without it, servers can drift apart and cause problems.
Imagine you have 100 computers that all need to have the same software installed. Doing it manually would take forever. Ansible is like a robot that installs the software on all 100 computers at the same time!
A company uses Ansible to install Nginx, PHP, and other software on all their web servers. They have a playbook that describes what to install, and Ansible does it automatically.
Your teacher uses a checklist to make sure every student has the same supplies. Ansible is like that checklist but for servers.
Your family has a checklist for packing for a trip. Everyone follows the checklist so nothing is forgotten. Ansible is like that checklist but for servers.
A Nigerian company uses Ansible to configure their servers. They have a playbook that sets up all the software they need. They can configure a new server in minutes.
ANSIBLE
+--------------------------------------------------+
| Ansible Control Machine |
| +-------------------------------------------+ |
| | Inventory (list of servers) | |
| | Playbook (what to do) | |
| | ───────────────────────────────────── | |
| | - name: Install Nginx | |
| | apt: | |
| | name: nginx | |
| | state: present | |
| +-------------------------------------------+ |
| | |
| V |
| Servers (No agent needed!) |
| +-------------------------------------------+ |
| | Server 1: Nginx installed | |
| | Server 2: Nginx installed | |
| | Server 3: Nginx installed | |
| | ... | |
| +-------------------------------------------+ |
| |
| 🔑 Ansible = Simple, agentless configuration! |
| |
+--------------------------------------------------+
Ansible is a configuration management tool that installs and configures software on servers. It is agentless, simple, and powerful.
Terraform and Ansible are both IaC tools, but they do different things. Terraform is for provisioning infrastructure (creating servers, networks, etc.). Ansible is for configuring infrastructure (installing software, setting up files, etc.).
Understanding the difference helps you choose the right tool for the right job. Many teams use both tools together.
Imagine you are building a house. Terraform is like the construction company that builds the house. Ansible is like the interior designer that furnishes and decorates the house. Both are needed for a complete home.
| Aspect | Terraform | Ansible |
|---|---|---|
| Primary Use | Provisioning infrastructure | Configuring infrastructure |
| What It Creates | Servers, networks, databases | Software, files, users |
| Approach | Declarative | Declarative or Imperative |
| State | Uses state files | Does not use state files |
| Agent | No agent needed | No agent needed |
| Best For | Creating infrastructure | Configuring servers |
A company uses Terraform to create AWS servers and Ansible to configure those servers with the right software. They work together perfectly.
Terraform is like building the classroom. Ansible is like putting up the posters and arranging the desks.
Terraform is like building a house. Ansible is like moving in the furniture and decorating.
A Nigerian company uses Terraform to create servers on AWS. Then they use Ansible to install their application on those servers. This gives them complete automation.
TERRAFORM VS ANSIBLE
TERRAFORM:
+--------------------------------------------------+
| Provisions infrastructure |
| Creates servers, networks, databases |
| "Build the house" |
| |
| Example: |
| resource "aws_instance" "web" { |
| ami = "ami-12345" |
| instance_type = "t2.micro" |
| } |
+--------------------------------------------------+
ANSIBLE:
+--------------------------------------------------+
| Configures infrastructure |
| Installs software, configures files |
| "Furnish the house" |
| |
| Example: |
| - name: Install Nginx |
| apt: |
| name: nginx |
| state: present |
+--------------------------------------------------+
🔑 Terraform builds, Ansible configures!
Terraform provisions infrastructure; Ansible configures it. Terraform builds the servers, and Ansible sets up the software. Many teams use both together.
The benefits of IaC are all the good things that happen when a team uses Infrastructure as Code. These include faster setup, fewer errors, and more consistency.
Understanding the benefits helps us see why IaC is so valuable. It helps us understand why so many teams are adopting IaC.
Imagine you have a magic wand that builds servers instantly, perfectly, and exactly the same every time. IaC is like having that magic wand!
| Benefit | What It Means |
|---|---|
| Speed | Infrastructure is created in minutes, not hours or days |
| Consistency | Every server is exactly the same |
| Reliability | Fewer errors because everything is automated |
| Reproducibility | Can rebuild infrastructure anytime |
| Version Control | Changes are tracked in Git |
| Cost Savings | Less time spent on manual tasks |
| Team Collaboration | Everyone works from the same code |
A company adopted IaC. Before, setting up a new environment took 2 days. After IaC, it took 5 minutes. They saved thousands of hours per year.
Your class uses a template for assignments. Everyone follows the same format, so grading is easier. IaC is like that template but for infrastructure.
Your family has a checklist for guests. Everyone follows the checklist so nothing is forgotten. IaC is like that checklist but for servers.
A Nigerian company adopted IaC. They went from spending days setting up servers to minutes. They saved money and could serve more customers.
THE BENEFITS OF IAC
+--------------------------------------------------+
| |
| ⚡ SPEED |
| Infrastructure in minutes |
| |
| ✅ CONSISTENCY |
| Every server is identical |
| |
| 🔒 RELIABILITY |
| Fewer errors |
| |
| 🔄 REPRODUCIBILITY |
| Rebuild anytime |
| |
| 📝 VERSION CONTROL |
| Changes tracked in Git |
| |
| 💰 COST SAVINGS |
| Less manual work |
| |
| 🤝 TEAM COLLABORATION |
| Everyone works from the same code |
| |
| ALL BECAUSE OF IAC! 🎉 |
| |
+--------------------------------------------------+
IaC has many benefits. It leads to speed, consistency, reliability, reproducibility, version control, cost savings, and team collaboration.
IaC and DevOps: IaC is a core part of DevOps. It provides the automation for managing infrastructure, which is essential for the fast delivery of software.
IaC and DevOps work together to help teams deliver software faster and more reliably. IaC provides the automation, and DevOps provides the culture and processes.
Imagine DevOps is a car. IaC is the engine that powers the car. Without IaC, DevOps would be slow and inefficient. With IaC, DevOps moves quickly and smoothly.
A company uses DevOps practices including IaC. Their infrastructure is defined in code, managed in Git, and deployed automatically. This allows them to deliver software quickly and reliably.
Your school has a system for managing resources. IaC is like the part that automatically allocates resources. DevOps is the whole system including planning, execution, and review.
Your family has a system for managing the household. IaC is like the automated system that orders supplies. DevOps is the whole system including planning, budgeting, and chores.
A Nigerian company uses DevOps and IaC. IaC is the engine that powers their DevOps pipeline. Without IaC, their DevOps would be slower and less reliable.
IAC AND DEVOPS
+--------------------------------------------------+
| |
| DEVOPS = CULTURE + TOOLS + PROCESSES |
| +-------------------------------------------+ |
| | 📋 Plan | |
| | 💻 Code | |
| | 🏗️ Build | |
| | ✅ Test | |
| | 🚀 Release | |
| | 🔄 Deploy ← IaC is here! | |
| | 📊 Operate ← IaC is here! | |
| | 👀 Monitor | |
| +-------------------------------------------+ |
| | |
| V |
| IAC IS A CORE PART OF DEVOPS |
| +-------------------------------------------+ |
| | ✅ IaC automates infrastructure | |
| | ✅ IaC ensures consistency | |
| | ✅ IaC enables speed | |
| +-------------------------------------------+ |
| |
| 🔑 IaC + DevOps = Powerful infrastructure! |
| |
+--------------------------------------------------+
IaC is a core part of DevOps. It provides the automation for managing infrastructure. Together, IaC and DevOps help teams deliver software quickly and reliably.
In this lesson, we will review everything we have learned about Infrastructure as Code. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use Terraform to provision servers and Ansible to configure them. Their infrastructure is managed entirely in code.
Your class has learned about IaC. They understand the importance of having a plan (code) for building things.
Your family has learned about IaC. They understand the importance of having checklists and recipes for consistency.
A Nigerian developer has learned all these IaC concepts. They can now manage infrastructure with code and help their company deliver better software.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 IaC = Infrastructure managed with code |
| 📌 IaC is faster, consistent, and reliable |
| 📌 Declarative = What; Imperative = How |
| 📌 Immutable = Never change, always replace |
| 📌 Terraform = Provision infrastructure |
| 📌 Terraform state = Track what is created |
| 📌 Ansible = Configure servers |
| 📌 Benefits: speed, consistency, reliability |
| 📌 IaC is a core part of DevOps |
| |
| YOU ARE NOW AN IAC BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about Infrastructure as Code. IaC helps teams manage infrastructure quickly, consistently, and reliably. It is a core part of DevOps.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Infrastructure as Code (IaC) | Managing infrastructure using code instead of manual processes |
| Declarative | Saying what you want, not how to do it |
| Imperative | Saying exactly how to do something |
| Immutable Infrastructure | Never changing servers; always creating new ones |
| Mutable Infrastructure | Making changes to existing servers |
| Terraform | A tool that provisions infrastructure (creates servers, etc.) |
| Terraform State | A file that tracks what Terraform has created |
| Configuration Management | Managing server configuration and software |
| Ansible | A configuration management tool |
| Playbook | An Ansible file that describes what to configure |
| Provisioning | Creating infrastructure (servers, networks, etc.) |
| Configuration | Setting up software and files on servers |
| Drift | When servers become different from each other |
| State Locking | Preventing two people from changing state at the same time |
| Idempotent | Running the same code multiple times does not cause problems |
Here are the most important concepts from this module. These are the big ideas that will help you understand Infrastructure as Code.
IaC manages infrastructure with code. Instead of manual processes, you write code to create, update, and delete infrastructure. This makes everything faster and more reliable.
Declarative is easier to maintain. Declarative says what you want, not how to do it. This is simpler and easier to understand.
Immutable infrastructure is more reliable. By never changing servers, you avoid configuration drift. Everything is consistent.
Terraform provisions infrastructure. Terraform creates servers, networks, and other infrastructure. It is declarative and works with many cloud providers.
Ansible configures infrastructure. Ansible installs software and sets up configurations on servers. It is simple and agentless.
IaC is a core part of DevOps. IaC provides the automation for managing infrastructure, which is essential for fast and reliable software delivery.
Let us look at how to set up IaC in simple steps:
Decide which tools to use. Terraform for provisioning and Ansible for configuration are a common combination.
Write your IaC code. For Terraform, you create .tf files. For Ansible, you create playbooks (YAML files).
Store your IaC code in a Git repository. This gives you version control and collaboration.
Run Terraform commands: terraform init (setup), terraform plan (preview), terraform apply (create infrastructure).
Run Ansible to configure your servers. Use ansible-playbook to run your playbooks.
When you need to make changes, update your code and run the tools again. Terraform will update infrastructure, and Ansible will update configurations.
STEP-BY-STEP: SETTING UP IAC
Step 1: CHOOSE TOOLS
+-------------------+
| Terraform + |
| Ansible |
+-------------------+
|
V
Step 2: WRITE CODE
+-------------------+
| .tf files for |
| Terraform |
| Playbooks for |
| Ansible |
+-------------------+
|
V
Step 3: STORE IN GIT
+-------------------+
| Push code to |
| Git repository |
+-------------------+
|
V
Step 4: RUN TERRAFORM
+-------------------+
| terraform init |
| terraform plan |
| terraform apply |
+-------------------+
|
V
Step 5: RUN ANSIBLE
+-------------------+
| ansible-playbook |
| playbook.yml |
+-------------------+
|
V
Step 6: MAINTAIN
+-------------------+
| Update code, |
| re-run tools |
+-------------------+
An e-commerce company uses Terraform to manage their AWS infrastructure. They have code that defines their servers, databases, and load balancers. When they need to scale, they just update the code and run Terraform.
A mobile app team uses Ansible to configure their servers. They have playbooks that install the app, set up the database, and configure monitoring. New servers are configured automatically.
A bank uses immutable infrastructure. When they need to update their system, they create new servers with the updates and switch traffic. This makes their system very reliable.
Flutterwave uses Terraform to manage their cloud infrastructure. They have their entire infrastructure defined in code. This helps them scale quickly and reliably.
Paystack uses Ansible to configure their servers. They have playbooks that set up their payment processing software. This ensures every server is configured correctly.
A Nigerian tech startup uses both Terraform and Ansible. Terraform creates their servers on AWS, and Ansible configures them. This gives them complete automation from scratch to running application.
You are building a LEGO castle. Instead of guessing, you have instructions. Every time you build it, it looks exactly the same. IaC is like having those instructions.
You are baking cookies. You have a recipe book. Every time you bake, you follow the recipe and the cookies are perfect. IaC is like having that recipe book.
You are packing for a trip. You have a checklist. Every time you pack, you follow the checklist and never forget anything. IaC is like having that checklist.
Your family has a grocery list. Every time you go shopping, you follow the list. IaC is like that list but for servers.
Your school has a timetable. Every day follows the same schedule. IaC is like that timetable but for infrastructure.
Your family has a budget. Every month, you follow the budget. IaC is like that budget but for infrastructure.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about Infrastructure as Code. Here are some tips to support their learning:
Mistake 1: Not using version control.
IaC code should be stored in Git. Without version control, you lose history and collaboration.
Mistake 2: Hard-coding values.
Hard-coding values (like IP addresses) makes your code brittle. Use variables and configuration files instead.
Mistake 3: Not using state locking.
When using remote state, always use state locking. This prevents conflicts when multiple people are working.
Mistake 4: Not testing your code.
IaC code should be tested. Use tools like Terratest to test your Terraform code.
Mistake 5: Using mutable infrastructure for everything.
Immutable infrastructure is better for most use cases. Only use mutable when you have a specific reason.
Mistake 6: Not planning before applying.
Always run terraform plan before terraform apply. This shows you what will change before you actually do it.
Use version control.
Store all your IaC code in Git. This gives you history, collaboration, and rollback capabilities.
Use variables.
Avoid hard-coding values. Use variables and configuration files to make your code reusable.
Use remote state with locking.
Store your Terraform state remotely and use state locking. This enables team collaboration and prevents conflicts.
Plan before applying.
Always run terraform plan first to see what will change. This helps you avoid surprises.
Use immutable infrastructure.
Prefer immutable infrastructure for most use cases. It is more reliable and consistent.
Test your code.
Test your IaC code just like you test application code. This helps you catch problems early.
Document your code.
Add comments and documentation to your IaC code. This helps others understand what it does.
IAC PIPELINE
+--------------------------------------------------+
| |
| CODE |
| +-------------------------------------------+ |
| | Write Terraform and Ansible code | |
| +-------------------------------------------+ |
| | |
| V |
| VERSION CONTROL |
| +-------------------------------------------+ |
| | Store code in Git | |
| +-------------------------------------------+ |
| | |
| V |
| TERRAFORM PROVISION |
| +-------------------------------------------+ |
| | Create servers, networks, databases | |
| +-------------------------------------------+ |
| | |
| V |
| ANSIBLE CONFIGURATION |
| +-------------------------------------------+ |
| | Install software, configure files | |
| +-------------------------------------------+ |
| | |
| V |
| INFRASTRUCTURE READY! |
| +-------------------------------------------+ |
| | 🚀 Everything is set up! | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
DECLARATIVE VS IMPERATIVE
DECLARATIVE:
+--------------------------------------------------+
| "I want a server with: |
| - 4GB RAM |
| - Ubuntu OS |
| - Nginx installed" |
| |
| ✅ Focus on result, not steps |
+--------------------------------------------------+
IMPERATIVE:
+--------------------------------------------------+
| Step 1: Download Ubuntu |
| Step 2: Install Ubuntu |
| Step 3: Install Nginx |
| Step 4: Configure Nginx |
| Step 5: Start Nginx |
| |
| ✅ Focus on exact steps |
+--------------------------------------------------+
IMMUTABLE INFRASTRUCTURE
MUTABLE:
+--------------------------------------------------+
| Server 1: Original |
| Update → Server 1: Changed |
| Update → Server 1: Changed again |
| Result: Server is different from others |
+--------------------------------------------------+
IMMUTABLE:
+--------------------------------------------------+
| Server 1: Original |
| Update → Create Server 2: Changed |
| Update → Create Server 3: Changed again |
| Result: All servers are identical |
+--------------------------------------------------+
| Aspect | Manual | IaC |
|---|---|---|
| Speed | Slow (hours or days) | Fast (minutes) |
| Consistency | Inconsistent | Consistent |
| Errors | Many human errors | Fewer errors |
| Reproducibility | Hard to reproduce | Easy to reproduce |
| History | No history | Full history in Git |
| Collaboration | Hard to collaborate | Easy to collaborate |
| Aspect | Terraform | Ansible |
|---|---|---|
| Primary Use | Provisioning infrastructure | Configuring infrastructure |
| What It Creates | Servers, networks, databases | Software, files, users |
| Approach | Declarative | Declarative or Imperative |
| State | Uses state files | Does not use state files |
| Agent | No agent needed | No agent needed |
| Aspect | Mutable | Immutable |
|---|---|---|
| Changes | Changes made to existing servers | New servers created for changes |
| Consistency | Servers drift apart | Servers are always identical |
| Fixing Problems | Fix the problem | Create new server and replace |
| Risk | Changes can break things | Always start from known good state |
| Example | Updating a server | Creating a new server |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 5 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Infrastructure as Code (IaC) is a practice where you manage infrastructure using code instead of manual processes. It makes setup fast, consistent, and repeatable.
Declarative says what you want. Imperative says how to do it. Declarative is easier to read and maintain. Imperative gives more control.
Immutable infrastructure means never changing servers after they are created. Instead, you create new servers with changes and replace the old ones. This keeps everything consistent and reliable.
Terraform provisions infrastructure (creates servers, networks, etc.). Ansible configures infrastructure (installs software, sets up files). Many teams use both together.
IaC leads to speed, consistency, reliability, reproducibility, version control, cost savings, and team collaboration. It is a core part of DevOps.
You have now completed Module 5! You are ready to move on to Module 6, where you will learn about Containerization and Orchestration with Docker and Kubernetes. Keep up the great work!
Q1: What is Infrastructure as Code?
A: Infrastructure as Code (IaC) is a practice where you manage infrastructure using code instead of manual processes.
Q2: Why is IaC important?
A: IaC is important because it makes infrastructure setup fast, consistent, and repeatable. It saves time and reduces errors.
Q3: What is the difference between declarative and imperative?
A: Declarative says what you want. Imperative says how to do it. Declarative is easier to read and maintain.
Q4: What is immutable infrastructure?
A: Immutable infrastructure means never changing servers after they are created. You create new servers with changes and replace the old ones.
Q5: What is Terraform?
A: Terraform is a popular IaC tool that provisions infrastructure (creates servers, networks, etc.).
Q6: What is Ansible?
A: Ansible is a configuration management tool that installs software and configures servers.
Q7: What is Terraform state?
A: Terraform state is a file that keeps track of what Terraform has created. It is like Terraform's memory.
Q8: What are the benefits of IaC?
A: IaC leads to speed, consistency, reliability, reproducibility, version control, cost savings, and team collaboration.
Q9: Is IaC part of DevOps?
A: Yes, IaC is a core part of DevOps. It provides the automation for managing infrastructure.
Q10: Is IaC used in Nigeria?
A: Yes, many Nigerian companies use IaC. It is helping them deliver better software and compete globally.
What is Infrastructure as Code?
Answer: Infrastructure as Code (IaC) is a practice where you manage infrastructure using code.
Why do we need IaC?
Answer: We need IaC because manual infrastructure management is slow, error-prone, and inconsistent.
What is declarative?
Answer: Declarative says what you want, not how to do it.
What is imperative?
Answer: Imperative says exactly how to do something.
What is immutable infrastructure?
Answer: Immutable infrastructure means never changing servers; always creating new ones.
What is Terraform?
Answer: Terraform is a tool that provisions infrastructure.
What is Ansible?
Answer: Ansible is a configuration management tool that configures servers.
What is Terraform state?
Answer: Terraform state is a file that tracks what Terraform has created.
What is the difference between Terraform and Ansible?
Answer: Terraform provisions infrastructure (builds servers). Ansible configures infrastructure (installs software).
Name two benefits of IaC.
Answer: Speed and consistency. (Other answers: reliability, reproducibility, version control, cost savings, collaboration.)
Is IaC part of DevOps?
Answer: Yes, IaC is a core part of DevOps.
What is state locking?
Answer: State locking prevents two people from changing state at the same time.
What is a playbook?
Answer: A playbook is an Ansible file that describes what to configure.
What is provisioning?
Answer: Provisioning is creating infrastructure (servers, networks, etc.).
Is IaC used in Nigeria?
Answer: Yes, many Nigerian companies use IaC.
Fill in the blanks with the correct words from the list:
Word list: Infrastructure as Code, declarative, imperative, immutable, Terraform, Ansible, state, provisioning, configuration, DevOps, playbook, drift
__________ is a practice where you manage infrastructure using code.
Answer: Infrastructure as Code
__________ says what you want, not how to do it.
Answer: declarative
__________ says exactly how to do something.
Answer: imperative
__________ infrastructure means never changing servers; always creating new ones.
Answer: immutable
__________ is a tool that provisions infrastructure.
Answer: Terraform
__________ is a configuration management tool.
Answer: Ansible
Terraform __________ is a file that tracks what Terraform has created.
Answer: state
__________ is creating infrastructure (servers, networks, etc.).
Answer: provisioning
__________ is setting up software and files on servers.
Answer: configuration
IaC is a core part of __________.
Answer: DevOps
An __________ file is called a playbook.
Answer: Ansible
When servers become different from each other, it is called __________.
Answer: drift
Write True or False for each statement:
IaC means managing infrastructure with code.
Answer: True
Manual infrastructure management is faster than IaC.
Answer: False (IaC is faster)
Declarative says what you want.
Answer: True
Imperative says what you want.
Answer: False (Imperative says how to do it)
Immutable infrastructure means never changing servers.
Answer: True
Terraform configures infrastructure.
Answer: False (Terraform provisions infrastructure)
Ansible provisions infrastructure.
Answer: False (Ansible configures infrastructure)
Terraform state tracks what Terraform has created.
Answer: True
IaC leads to more errors.
Answer: False (IaC leads to fewer errors)
IaC is a core part of DevOps.
Answer: True
State locking prevents conflicts.
Answer: True
Ansible uses a language called YAML.
Answer: True
IaC is only used by large companies.
Answer: False (It is used by companies of all sizes)
Immutable infrastructure is more reliable than mutable.
Answer: True
IaC is not used in Nigeria.
Answer: False
Choose the correct answer for each question:
What is Infrastructure as Code?
A) A type of computer
B) Managing infrastructure with code
C) A programming language
D) A video game
Answer: B
What is declarative?
A) Saying how to do something
B) Saying what you want
C) A type of server
D) A programming language
Answer: B
What is imperative?
A) Saying how to do something
B) Saying what you want
C) A type of server
D) A programming language
Answer: A
What is immutable infrastructure?
A) Changing servers frequently
B) Never changing servers; always creating new ones
C) A type of server
D) A programming language
Answer: B
What does Terraform do?
A) Configures servers
B) Provisions infrastructure
C) Installs software
D) Manages users
Answer: B
What does Ansible do?
A) Provisions infrastructure
B) Configures servers
C) Creates networks
D) Manages databases
Answer: B
What is Terraform state?
A) A programming language
B) A file that tracks what Terraform has created
C) A type of server
D) A configuration file
Answer: B
What is state locking?
A) Locking files
B) Preventing two people from changing state at the same time
C) A type of server
D) A programming language
Answer: B
What is a playbook?
A) A Terraform file
B) An Ansible file that describes what to configure
C) A type of server
D) A programming language
Answer: B
What is provisioning?
A) Installing software
B) Creating infrastructure
C) Configuring servers
D) Managing users
Answer: B
What is configuration?
A) Creating infrastructure
B) Setting up software and files
C) A type of server
D) A programming language
Answer: B
Is IaC part of DevOps?
A) No
B) Yes, it is a core part
C) Sometimes
D) Only for large companies
Answer: B
What is a benefit of IaC?
A) Slower setup
B) More errors
C) Consistency
D) Less collaboration
Answer: C
Is IaC used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
What is drift?
A) When servers are identical
B) When servers become different from each other
C) When servers are created
D) When servers are deleted
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Infrastructure as Code | A. Saying what you want |
| 2. Declarative | B. Never changing servers; always creating new ones |
| 3. Imperative | C. A tool that provisions infrastructure |
| 4. Immutable | D. A configuration management tool |
| 5. Terraform | E. Managing infrastructure with code |
| 6. Ansible | F. Saying how to do something |
| 7. State | G. Preventing conflicts when multiple people work |
| 8. Provisioning | H. Creating infrastructure |
| 9. Configuration | I. Setting up software and files |
| 10. State Locking | J. A file that tracks what Terraform has created |
Answers:
What is Infrastructure as Code and why is it useful?
Answer: Infrastructure as Code (IaC) is a practice where you manage infrastructure using code. It is useful because it makes infrastructure setup fast, consistent, and repeatable. It saves time and reduces errors.
Explain the difference between declarative and imperative.
Answer: Declarative says what you want, not how to do it. It focuses on the final result. Imperative says exactly how to do something. It focuses on the exact steps.
What is immutable infrastructure and why is it better?
Answer: Immutable infrastructure means never changing servers after they are created. Instead, you create new servers with changes and replace the old ones. It is better because it keeps everything consistent and prevents configuration drift.
Compare Terraform and Ansible.
Answer: Terraform provisions infrastructure (creates servers, networks, etc.). Ansible configures infrastructure (installs software, sets up files). Terraform is declarative. Ansible can be declarative or imperative. Many teams use both together.
How does IaC support DevOps?
Answer: IaC is a core part of DevOps. It provides the automation for managing infrastructure. IaC enables speed, consistency, and reliability. It supports collaboration by storing code in Git. Together, IaC and DevOps help teams deliver software quickly and reliably.
A company takes 2 days to set up a new server. They do everything manually. They often make mistakes. They want to speed things up.
Question: How could IaC help this company?
Answer: IaC could help by automating the entire setup process. They would write code that describes the server. Then they would run the code to create the server automatically. This would take minutes instead of days and eliminate human errors.
A company has 20 servers. They are all configured differently. Some have different software versions. Some have different settings. This causes problems.
Question: How could IaC fix this problem?
Answer: IaC could fix this by ensuring all servers are created from the same code. Every server would be exactly the same. They could use Terraform to create the servers and Ansible to configure them. This would eliminate inconsistency.
A Nigerian startup wants to use IaC. They are building their infrastructure on AWS. They have 3 developers. They want to manage everything with code.
Question: What should the startup do to implement IaC?
Answer: The startup should use Terraform to provision their AWS infrastructure. They should write Terraform code that defines their servers, databases, and networks. They should store the code in Git. They could also use Ansible to configure their servers. This would give them complete automation.
Instructions:
Instructions:
Why do you think using code to manage infrastructure is better than doing it manually?
Discuss with your classmates and share your ideas.
Have you ever had to repeat the same task over and over? How did it make you feel?
Share your experiences and thoughts.
What are some other situations where having a recipe or checklist is helpful?
Think about school, home, and other activities.
Do you think immutable infrastructure is always better than mutable? Why or why not?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from IaC?
Share examples of companies in Nigeria.
What do you think is the most important part of IaC?
Explain why you think so.
Do you think IaC is easy to learn? Why or why not?
Share your thoughts.
What is the most important thing you learned about IaC today?
Share with the class.
Goal: Create a simple guide to teach beginners about Infrastructure as Code.
Instructions:
Goal: Learn about real-world IaC practice.
Instructions:
Scenario:
You are an IaC architect at a Nigerian company. The company has 20 developers working on a large web application. They want to implement IaC to manage their infrastructure on AWS.
The company has:
Challenge: Create a complete IaC implementation plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 5: "Infrastructure as Code (IaC)." You now understand how teams manage infrastructure with code, using tools like Terraform and Ansible.
In Module 6, you will learn:
Before you start Module 6, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 6! 🚀
© 2026 Certified DevOps Engineer Course • Module 5: Infrastructure as Code (IaC)
Welcome to Module 6 of our Certified DevOps Engineer course! This module is called "Containerization & Orchestration: Packaging and Managing Software with Docker & Kubernetes."
In this module, we will learn about containers — a way to package software so it runs the same everywhere — and Kubernetes — a tool that manages many containers automatically.
Think of containers like lunchboxes. You put your food in a lunchbox, and it stays fresh and organized. You can take it anywhere, and it looks the same whether you are at home, at school, or at a friend's house. Containers do the same thing for software!
Hello and welcome back! In Module 1, we learned about DevOps. In Module 2, we learned about Git. In Module 3, we learned about Continuous Integration. In Module 4, we learned about Continuous Delivery. In Module 5, we learned about Infrastructure as Code. Now, in Module 6, we are going to learn about Containerization and Orchestration.
Have you ever had a problem where software works on one computer but not on another? This is a very common problem. Developers say "It works on my machine!" but when they try to run it somewhere else, it breaks. Containers solve this problem!
A container is like a magic box that contains everything a program needs to run. It has the code, the settings, and all the pieces it needs. When you put a program in a container, it will run the same way on any computer.
But what if you have hundreds or thousands of containers? How do you manage them all? That is where Kubernetes comes in. Kubernetes is like a ship captain that manages a fleet of container ships. It makes sure everything is running smoothly and fixes problems automatically.
In this module, we will learn all about containers, Docker, and Kubernetes. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover the amazing world of containers!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company called "FoodApp." They built an app that helped people order food from restaurants.
The company had a big problem. Their app worked perfectly on the developer's computer. But when they tried to run it on the server, it would break. Sometimes the app worked on one server but not on another. This was very frustrating!
The developers would say, "It works on my computer!" But the operations team would say, "It does not work on our servers!" They spent many hours trying to fix problems that only happened on some computers.
One day, a clever engineer named Mr. Kunle discovered something called containers. He learned that a container was like a magic lunchbox. You put your app in the lunchbox, and it contains everything the app needs to run. The app runs the same way whether it is on a developer's computer or on a server!
Mr. Kunle started using Docker, a tool that creates these magic lunchboxes. Now, every time they built the app, they put it in a container. The app ran perfectly everywhere. No more "It works on my computer" problems!
But soon, the company had hundreds of containers. Managing them all became a new problem. That is when they discovered Kubernetes. Kubernetes was like a ship captain that managed all the containers automatically. It started new containers when they were needed, restarted containers that failed, and made sure everything was running smoothly.
FoodApp grew and became one of the most successful food delivery apps in Nigeria. And it was all because of containers and Kubernetes!
This story shows us how containers and Kubernetes help teams build and run software reliably. Let us learn more about these amazing tools!
A container is a way to package software so it includes everything it needs to run. It is like a lunchbox that contains your food, utensils, and napkin — everything you need for a meal.
Containers are important because they make software run the same way everywhere. If it works in a container on your computer, it will work in a container on any other computer.
Imagine you are moving to a new house. You pack your toys in a box. The box has everything you need to play with your toys — the toys, the batteries, and the instructions. When you open the box at your new house, everything is there and ready to use. A container is like that box for software!
A company builds a web app using Python. They put the app in a container with Python and all the libraries it needs. The container runs the same way on the developer's laptop, the test server, and the live server.
Your class has a science project. You put all the materials you need in a box — the instructions, the chemicals, the tools. You can do the experiment anywhere because everything is in the box. A container is like that box for software.
Your family has a first aid kit. It has bandages, medicine, and instructions. You can use it anywhere because everything is in the kit. A container is like that first aid kit for software.
A Nigerian fintech company uses containers to package their payment app. The app runs the same way on all their servers. This makes it easier to add new servers and keep the app running smoothly.
WHAT IS A CONTAINER?
+--------------------------------------------------+
| |
| CONTAINER (Like a Lunchbox) |
| +-------------------------------------------+ |
| | 🍔 App Code | |
| | 🧰 Runtime (Python, Java, etc.) | |
| | 📚 Libraries | |
| | ⚙️ Settings | |
| | 🔗 Dependencies | |
| +-------------------------------------------+ |
| |
| Runs the SAME way EVERYWHERE! |
| +-------------------------------------------+ |
| | 💻 Developer Laptop = ✅ Works | |
| | 🖥️ Test Server = ✅ Works | |
| | ☁️ Production Server = ✅ Works | |
| +-------------------------------------------+ |
| |
| 🔑 Containers = Software that travels well! |
| |
+--------------------------------------------------+
A container is a package that contains everything a program needs to run. It makes software run the same way everywhere. It is like a lunchbox for your code.
Why we need containers: We need containers because software often works differently on different computers. This is called "works on my machine" problem. Containers solve this problem.
Containers are important because they save time, reduce problems, and make it easier for teams to work together. They are a key tool in DevOps.
Imagine you have a recipe for your favorite cake. You make it at your friend's house, but it does not taste the same. Why? Because your friend's oven is different, the ingredients are different, and the kitchen tools are different.
Containers are like a magical portable kitchen. You put all the ingredients, tools, and instructions in one box. You can bake the cake in any kitchen, and it will taste exactly the same!
| Problem | What It Means | Container Solution |
|---|---|---|
| Works on My Machine | Software works on developer's computer but not on servers | Containers run the same everywhere |
| Dependency Conflicts | Different programs need different versions of the same library | Containers isolate dependencies |
| Slow Setup | Setting up a new environment takes hours or days | Containers start in seconds |
| Hard to Scale | Adding more copies of the software is difficult | Containers can be duplicated easily |
| Inconsistent Environments | Development, testing, and production are all different | Containers are the same everywhere |
A company used to spend a full day setting up a new server. With containers, they start a new container in seconds. They can add new servers instantly when they need more power.
Your class has a group project. Everyone works on their own computer. With containers, everyone has the exact same setup. No one says "It works on my computer!" because it works on everyone's computer.
Your family has a favorite meal. You want to share it with your friends. If you give them a container with all the ingredients and instructions, they can make the same meal at their house. Containers are like that for software.
A Nigerian tech startup has developers in Lagos, Abuja, and Port Harcourt. They use containers so everyone has the same development environment. No more "works on my machine" problems!
WHY WE NEED CONTAINERS
WITHOUT CONTAINERS:
+--------------------------------------------------+
| Developer 1: "It works on my computer!" |
| Developer 2: "It does not work on mine!" |
| Server: "It does not work here either!" |
| ❌ Chaos, confusion, wasted time |
+--------------------------------------------------+
WITH CONTAINERS:
+--------------------------------------------------+
| Developer 1: Container → ✅ Works |
| Developer 2: Container → ✅ Works |
| Server: Container → ✅ Works |
| ✅ Consistent, reliable, fast! |
+--------------------------------------------------+
We need containers because they make software run the same way everywhere. They solve the "works on my machine" problem and make development faster and more reliable.
Docker is the most popular tool for creating and running containers. It was created in 2013 and has become very popular because it makes containers easy to use.
Docker is important because it made containers simple and accessible. Before Docker, containers were hard to use. Docker made them easy for everyone.
Imagine you want to pack a lunch. You need a lunchbox. Docker is like the company that makes the best lunchboxes. They make it easy to pack your food, keep it fresh, and carry it anywhere. Docker does the same thing for software!
| Concept | What It Is | Analogy |
|---|---|---|
| Docker Image | A blueprint for a container | A recipe for a cake |
| Docker Container | A running instance of an image | The baked cake |
| Dockerfile | A text file with instructions to build an image | The written recipe |
| Docker Registry | A place to store and share images | A library of recipes |
| Docker Hub | A public registry for Docker images | A big public library |
A company uses Docker to package their web app. They create a Dockerfile that describes the app. They build a Docker image from the Dockerfile. They run containers from the image on their servers.
Your class is making a school newspaper. You have a template (the image). Each week, you create a new newspaper (the container) from the template. Docker is like that template for software.
Your family has a recipe for cookies (the image). You bake cookies (the container) from the recipe. You can bake many batches (many containers) from the same recipe (the image). Docker is like that recipe.
A Nigerian company uses Docker to package their mobile app backend. They have a Docker image that contains the app. They run containers from this image on AWS. This makes it easy to scale the app.
DOCKER BASICS
+--------------------------------------------------+
| DOCKERFILE (Recipe) |
| +-------------------------------------------+ |
| | FROM python:3.9 | |
| | WORKDIR /app | |
| | COPY . . | |
| | RUN pip install -r requirements.txt | |
| | CMD python app.py | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER IMAGE (Blueprint) |
| +-------------------------------------------+ |
| | 📦 app:latest | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER CONTAINER (Running instance) |
| +-------------------------------------------+ |
| | 🚀 The app is running! | |
| +-------------------------------------------+ |
| |
| 🔑 Docker makes containers easy! |
| |
+--------------------------------------------------+
Docker is the most popular tool for creating and running containers. It uses images (blueprints), containers (running instances), and Dockerfiles (recipes). Docker made containers easy for everyone.
A Docker image is like a blueprint or a recipe. It contains everything needed to run the software, but it is not running. A Docker container is a running instance of an image. It is the actual software running.
Understanding the difference is important because images are used to create containers. You can have many containers from the same image, just like you can bake many cakes from the same recipe.
Imagine you have a cookie recipe (the image). You follow the recipe to bake cookies (the container). You can bake many batches of cookies from the same recipe. Each batch is a container. The recipe is the image.
| Aspect | Docker Image | Docker Container |
|---|---|---|
| What It Is | A blueprint or recipe | A running instance |
| State | Not running (static) | Running (active) |
| Can Be Modified | No (read-only) | Yes (can change while running) |
| Analogy | A recipe for cake | A baked cake |
| Storage | Stored in a registry | Running on a computer |
| Multiple | One image can make many containers | Many containers can run from one image |
A company has a Docker image for their web app. They run 5 containers from this image to handle traffic. If they need more, they just start more containers from the same image.
Your teacher has a lesson plan (the image). The teacher teaches the lesson to each class (the containers). Each class is a different container, but the lesson plan is the same.
Your family has a favorite smoothie recipe (the image). You make smoothies for breakfast (the containers). Each morning, you make a new smoothie from the same recipe.
A Nigerian company has a Docker image for their payment service. They run containers from this image on different servers. Each container handles payments for different customers.
IMAGE VS CONTAINER
+--------------------------------------------------+
| DOCKER IMAGE (Recipe) |
| +-------------------------------------------+ |
| | 📦 app:latest | |
| | Blueprint for the app | |
| | Not running, just stored | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER CONTAINER 1 (Running) |
| +-------------------------------------------+ |
| | 🚀 App is running! | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER CONTAINER 2 (Running) |
| +-------------------------------------------+ |
| | 🚀 App is running! | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER CONTAINER 3 (Running) |
| +-------------------------------------------+ |
| | 🚀 App is running! | |
| +-------------------------------------------+ |
| |
| 🔑 One image, many containers! |
| |
+--------------------------------------------------+
A Docker image is a blueprint. A Docker container is a running instance of that blueprint. You can run many containers from one image, just like you can bake many cakes from one recipe.
A Dockerfile is a text file that contains instructions on how to build a Docker image. It is like a recipe that tells Docker exactly what to do.
The Dockerfile is important because it is how you create your own Docker images. You write the instructions, and Docker builds the image for you.
Imagine you want to teach a robot how to bake a cake. You write down step-by-step instructions. The robot reads the instructions and bakes the cake. A Dockerfile is like those instructions for Docker.
| Command | What It Does | Example |
|---|---|---|
| FROM | Starts from an existing image | FROM python:3.9 |
| WORKDIR | Sets the working directory inside the container | WORKDIR /app |
| COPY | Copies files into the container | COPY . . |
| RUN | Runs commands inside the container | RUN pip install -r requirements.txt |
| CMD | Specifies the command to run when the container starts | CMD python app.py |
| EXPOSE | Opens a port for the container | EXPOSE 8080 |
A company has a Dockerfile that installs their app and all dependencies. When they build the image, Docker reads the Dockerfile and creates an image with everything the app needs.
Your teacher gives you a list of steps to build a model. You follow the steps and build the model. A Dockerfile is like that list of steps.
Your family has a recipe card. It tells you step by step how to make your favorite meal. A Dockerfile is like that recipe card for software.
A Nigerian developer writes a Dockerfile for their app. It says "Start from Ubuntu, install Python, copy the code, run the app." They build the image and run it on their servers.
DOCKERFILE EXAMPLE
+--------------------------------------------------+
| Dockerfile (Recipe) |
| +-------------------------------------------+ |
| | # Start from Python 3.9 image | |
| | FROM python:3.9 | |
| | | |
| | # Set working directory | |
| | WORKDIR /app | |
| | | |
| | # Copy code into the container | |
| | COPY . . | |
| | | |
| | # Install dependencies | |
| | RUN pip install -r requirements.txt | |
| | | |
| | # Run the app | |
| | CMD python app.py | |
| +-------------------------------------------+ |
| | |
| V |
| docker build -t myapp . |
| +-------------------------------------------+ |
| | Image "myapp" is built! | |
| +-------------------------------------------+ |
| |
| 🔑 Dockerfile = Instructions for building! |
| |
+--------------------------------------------------+
A Dockerfile is a text file with instructions to build a Docker image. It is like a recipe that tells Docker exactly what to do. Common commands include FROM, WORKDIR, COPY, RUN, and CMD.
The container lifecycle is the series of stages a container goes through from creation to deletion. It is like the life of a plant: seed → sprout → plant → flower → seed.
Understanding the container lifecycle helps you know how to manage containers. You know when to start them, stop them, and remove them.
Imagine you are making a sandwich. First, you gather the ingredients (create the image). Then, you make the sandwich (run the container). You eat it (the container runs). When you are done, you clean up (stop and remove the container).
| Stage | What Happens | Docker Command |
|---|---|---|
| Create | The container is created from the image | docker create |
| Start | The container starts running | docker start |
| Run | The container is running and doing its work | docker run (create + start) |
| Pause/Resume | Pause temporarily, then resume | docker pause / docker unpause |
| Stop | The container stops running | docker stop |
| Remove | The container is deleted | docker rm |
A company runs containers for their web app. When they need to deploy a new version, they create new containers, start them, and stop the old ones.
Your class has a project cycle: plan, create, present, and clean up. The container lifecycle is like that for software.
Your family has a routine: plan the meal, cook it, eat it, and clean up. The container lifecycle is like that for containers.
A Nigerian company uses containers for their app. They create containers, run them, and when they need to update, they stop the old ones and start new ones.
CONTAINER LIFECYCLE
+--------------------------------------------------+
| |
| 1. CREATE |
| +-------------------------------------------+ |
| | docker create myapp | |
| | Container is created from image | |
| +-------------------------------------------+ |
| | |
| V |
| 2. START |
| +-------------------------------------------+ |
| | docker start mycontainer | |
| | Container starts running | |
| +-------------------------------------------+ |
| | |
| V |
| 3. RUNNING |
| +-------------------------------------------+ |
| | docker run myapp | |
| | App is working! | |
| +-------------------------------------------+ |
| | |
| V |
| 4. STOP |
| +-------------------------------------------+ |
| | docker stop mycontainer | |
| | Container stops running | |
| +-------------------------------------------+ |
| | |
| V |
| 5. REMOVE |
| +-------------------------------------------+ |
| | docker rm mycontainer | |
| | Container is deleted | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------+
The container lifecycle has five stages: create, start, run, stop, and remove. Containers go through these stages from creation to deletion.
Kubernetes (also called K8s) is a tool that manages containers automatically. It is like a ship captain that manages a fleet of container ships. Kubernetes was created by Google and is now used by companies all over the world.
Kubernetes is important because it automates the management of containers. If you have hundreds or thousands of containers, you need a way to manage them. Kubernetes does this automatically.
Imagine you have many robots that need to do tasks. You could manage each robot yourself, but that would be hard. Kubernetes is like a robot manager. It tells the robots what to do, makes sure they are working, and fixes problems automatically.
A company uses Kubernetes to manage their web app. They have 50 containers running. If a container fails, Kubernetes starts a new one. If traffic increases, Kubernetes starts more containers.
Your school has many classrooms. The principal (Kubernetes) makes sure each classroom has a teacher (container), replaces teachers who are sick (self-healing), and adds more classrooms when there are more students (scaling).
Your family has many chores. The chore manager (Kubernetes) assigns tasks, makes sure they are done, and reassigns them if someone is busy (self-healing). It adds more helpers when there is more work (scaling).
A Nigerian fintech uses Kubernetes to manage their payment app. They have many containers running. Kubernetes automatically scales up during peak hours and scales down at night. This saves money and keeps the app running smoothly.
WHAT IS KUBERNETES?
+--------------------------------------------------+
| KUBERNETES (Ship Captain) |
| +-------------------------------------------+ |
| | Manages many containers | |
| | Scales up when needed | |
| | Heals failed containers | |
| | Updates without downtime | |
| | Load balances traffic | |
| +-------------------------------------------+ |
| | |
| V |
| MANY CONTAINERS (Ships) |
| +-------------------------------------------+ |
| | 🚢 Container 1 🚢 Container 2 | |
| | 🚢 Container 3 🚢 Container 4 | |
| | 🚢 Container 5 🚢 Container 6 | |
| +-------------------------------------------+ |
| |
| 🔑 Kubernetes = Automated container management! |
| |
+--------------------------------------------------+
Kubernetes is a tool that manages containers automatically. It scales containers, heals failed ones, and updates without downtime. It is like a ship captain for a fleet of container ships.
Kubernetes architecture is the structure of Kubernetes. It has different parts that work together to manage containers. It is like the parts of a car that work together to make it go.
Understanding Kubernetes architecture helps you know how it works. When you understand the parts, you can use Kubernetes more effectively.
Imagine a school. The principal (control plane) manages everything. The teachers (nodes) teach the students (containers). Each classroom (pod) has one or more students. This is how Kubernetes works too!
| Component | What It Is | Analogy |
|---|---|---|
| Control Plane | The brain of Kubernetes | School principal |
| Node | A computer that runs containers | A classroom |
| Pod | A group of one or more containers | A student desk |
| Service | A way to access pods | A classroom door |
| Deployment | Manages pods and scaling | Teacher's lesson plan |
| Namespace | A way to organize resources | A school grade level |
| Ingress | A way to route external traffic | The school main entrance |
A company runs Kubernetes. They have a cluster with 3 nodes. Each node runs multiple pods. A service makes the pods accessible. A deployment manages the pods.
Your school has a principal (control plane). There are classrooms (nodes). Each classroom has students (pods). The classroom door (service) lets people in. The teacher (deployment) manages the students.
Your family has a home manager (control plane). There are rooms (nodes). Each room has furniture (pods). The room door (service) lets people in. The chore list (deployment) manages tasks.
A Nigerian company has a Kubernetes cluster on AWS. They have 5 nodes. Each node runs several pods. The pods run their app. Kubernetes manages everything automatically.
KUBERNETES ARCHITECTURE
+--------------------------------------------------+
| CONTROL PLANE (Brain) |
| +-------------------------------------------+ |
| | 📋 API Server | |
| | 📊 Scheduler | |
| | 🔄 Controller Manager | |
| +-------------------------------------------+ |
| | |
| V |
| NODES (Computers) |
| +-------------------------------------------+ |
| | Node 1 | |
| | +----------------------------------+ | |
| | | Pod 1 │ Pod 2 │ Pod 3 | | |
| | +----------------------------------+ | |
| +-------------------------------------------+ |
| | Node 2 | |
| | +----------------------------------+ | |
| | | Pod 1 │ Pod 2 │ Pod 3 | | |
| | +----------------------------------+ | |
| +-------------------------------------------+ |
| | Node 3 | |
| | +----------------------------------+ | |
| | | Pod 1 │ Pod 2 │ Pod 3 | | |
| | +----------------------------------+ | |
| +-------------------------------------------+ |
| |
| 🔑 Kubernetes has a brain and many workers! |
| |
+--------------------------------------------------+
Kubernetes architecture has a control plane and nodes. The control plane is the brain. Nodes are computers that run pods (containers). Services, deployments, and namespaces help organize and manage everything.
A pod is the smallest unit in Kubernetes. It is a group of one or more containers that run together. A pod is like a room where containers live together.
Pods are important because they are the basic building block of Kubernetes. Everything you do in Kubernetes starts with pods.
Imagine you are living in a house. The house has rooms. Each room is a pod. You can have one person (container) in a room, or you can have several people (containers) sharing a room. The room is the pod.
A company runs a web app in Kubernetes. Each pod runs one container with the web app. They have many pods for the web app. Each pod is like a copy of the app.
Your school has classrooms. Each classroom (pod) has students (containers). Some classrooms have one teacher, some have two. Each classroom is a pod.
Your family has rooms in your house. Each room (pod) has family members (containers). Some rooms have one person, some have more. Each room is a pod.
A Nigerian company runs their app in Kubernetes. They have 20 pods running the app. If a pod fails, Kubernetes starts a new one. This keeps their app running.
KUBERNETES PODS
+--------------------------------------------------+
| POD 1 (A Room) |
| +-------------------------------------------+ |
| | 🐳 Container 1 (App) | |
| | 🐳 Container 2 (Helper) | |
| +-------------------------------------------+ |
| |
| POD 2 (A Room) |
| +-------------------------------------------+ |
| | 🐳 Container 1 (App) | |
| +-------------------------------------------+ |
| |
| POD 3 (A Room) |
| +-------------------------------------------+ |
| | 🐳 Container 1 (App) | |
| +-------------------------------------------+ |
| |
| 🔑 Pods = Rooms where containers live! |
| |
+--------------------------------------------------+
A pod is the smallest unit in Kubernetes. It is a group of one or more containers that run together. Pods are like rooms where containers live.
A deployment in Kubernetes is a way to manage pods. It tells Kubernetes how many pods to run, what image to use, and how to update them. It is like a manager for your pods.
Deployments are important because they make it easy to scale and update your app. You tell the deployment what you want, and Kubernetes makes it happen.
Imagine you are a manager at a restaurant. You tell your staff how many tables to set up, how many waiters to have, and what to do when a waiter leaves. A deployment is like that manager for your pods.
A company has a deployment for their web app. The deployment says "run 10 pods of version 2.0." If traffic increases, they change it to "run 20 pods." Kubernetes automatically starts more pods.
Your school has a schedule (deployment). It says how many teachers (pods) are needed for each subject. If more students join, the schedule is updated to have more teachers.
Your family has a chore list (deployment). It says who does which chores (pods). If someone is sick, the list is updated to reassign the chores.
A Nigerian company uses deployments to manage their app. They have a deployment that runs 5 pods. During peak hours, they scale up to 10 pods. Kubernetes does this automatically.
KUBERNETES DEPLOYMENTS
+--------------------------------------------------+
| DEPLOYMENT |
| +-------------------------------------------+ |
| | replicas: 5 | |
| | image: myapp:latest | |
| | update strategy: rolling | |
| +-------------------------------------------+ |
| | |
| V |
| PODS (Created and managed by deployment) |
| +-------------------------------------------+ |
| | Pod 1 │ Pod 2 │ Pod 3 │ Pod 4 | |
| | Pod 5 | |
| +-------------------------------------------+ |
| |
| 🔑 Deployments manage pods automatically! |
| |
+--------------------------------------------------+
A deployment manages pods in Kubernetes. It handles scaling, rolling updates, rollbacks, and self-healing. It is like a manager for your pods.
A service in Kubernetes is a way to access your pods. It is like a door that lets people into your app. Services make pods discoverable and load balance traffic.
Services are important because pods can come and go. They can be created and destroyed. A service gives you a stable way to access your app.
Imagine a hotel. The hotel has many rooms (pods). Guests come and go (pods change). But the front desk (service) is always there. You go to the front desk to get a room. The front desk gives you a room that is available.
| Type | What It Does | Analogy |
|---|---|---|
| ClusterIP | Internal access only | An internal office door |
| NodePort | External access on a port | A door from the street |
| LoadBalancer | External access via a cloud load balancer | A front door with a doorman |
| Ingress | HTTP/HTTPS routing | A reception desk |
A company has a service for their web app. The service makes the app accessible to users. When new pods are created, the service automatically starts sending traffic to them.
Your school has a main office (service). Students go to the office to get information. The office directs them to the right classroom (pod).
Your family has a phone number (service). People call the number to reach your family. The phone directs the call to whoever is available (pod).
A Nigerian company has a service for their app. Users access the app through the service. The service balances traffic across all pods. This makes their app fast and reliable.
KUBERNETES SERVICES
+--------------------------------------------------+
| SERVICE (Front Desk) |
| +-------------------------------------------+ |
| | Stable IP address | |
| | Load balances traffic | |
| | Always available | |
| +-------------------------------------------+ |
| | |
| V |
| PODS (Rooms) |
| +-------------------------------------------+ |
| | Pod 1 │ Pod 2 │ Pod 3 │ Pod 4 | |
| +-------------------------------------------+ |
| |
| USER → SERVICE → POD |
| +-------------------------------------------+ |
| | 👤 User requests app | |
| | 🚪 Service directs to available pod | |
| | 🐳 App responds | |
| +-------------------------------------------+ |
| |
| 🔑 Services = Doors to your app! |
| |
+--------------------------------------------------+
A service is a way to access your pods. It provides a stable address and load balances traffic. Services make pods discoverable even when they change.
A namespace in Kubernetes is a way to organize resources. It is like having different folders for different projects. Namespaces help keep things separate and organized.
Namespaces are important because they help you organize your Kubernetes resources. Without namespaces, everything would be in one big messy pile.
Imagine you have a big box of LEGOs. All the pieces are mixed together. It is hard to find what you need. Now imagine you have separate boxes for different projects — one for the castle, one for the spaceship, one for the house. Namespaces are like those separate boxes.
A company has different namespaces for different teams. Development team uses "dev" namespace. Testing team uses "test" namespace. Production team uses "prod" namespace. This keeps everything organized.
Your school has different grades. Grade 1, Grade 2, Grade 3. Each grade is like a namespace. Students (resources) in Grade 1 are separate from students in Grade 2.
Your family has different rooms for different things. Kitchen for cooking, bedroom for sleeping, living room for relaxing. Each room is like a namespace.
A Nigerian company has namespaces for their different apps. They have a namespace for the payment app, one for the user app, and one for the admin app. This keeps everything organized and secure.
KUBERNETES NAMESPACES
+--------------------------------------------------+
| NAMESPACE: dev |
| +-------------------------------------------+ |
| | Pod 1 Pod 2 Pod 3 | |
| +-------------------------------------------+ |
| |
| NAMESPACE: test |
| +-------------------------------------------+ |
| | Pod 1 Pod 2 Pod 3 | |
| +-------------------------------------------+ |
| |
| NAMESPACE: prod |
| +-------------------------------------------+ |
| | Pod 1 Pod 2 Pod 3 | |
| +-------------------------------------------+ |
| |
| 🔑 Namespaces organize resources! |
| |
+--------------------------------------------------+
Namespaces organize Kubernetes resources. They are like folders for your projects. They keep things separate and organized.
The benefits of containers and Kubernetes are all the good things that happen when you use them. These include consistency, scalability, and reliability.
Understanding the benefits helps us see why containers and Kubernetes are so popular. They are used by almost every modern software company.
Imagine you have a magic machine that can copy itself, heal itself, and grow when you need more power. Containers and Kubernetes are like that magic machine for software!
| Benefit | What It Means |
|---|---|
| Consistency | Software runs the same everywhere |
| Scalability | Can handle more users by adding containers |
| Reliability | Self-healing restarts failed containers |
| Speed | Containers start in seconds |
| Portability | Containers work on any computer |
| Resource Efficiency | Containers use less resources than virtual machines |
| DevOps Enablement | Makes CI/CD pipelines work smoothly |
A company adopted containers and Kubernetes. They went from deploying once a month to deploying multiple times a day. They could handle 10x more traffic without any problems.
Your school uses containers for their website. When many parents try to access the website at the same time, it stays fast because containers scale up automatically.
Your family uses containers for a shared calendar. The calendar is always available and never crashes. If one container fails, another one takes over.
A Nigerian e-commerce company used containers and Kubernetes. They could handle the huge traffic during Black Friday because Kubernetes scaled up automatically. Their website never went down.
BENEFITS OF CONTAINERS AND KUBERNETES
+--------------------------------------------------+
| |
| ✅ CONSISTENCY |
| Works the same everywhere |
| |
| 📈 SCALABILITY |
| Grows to handle more users |
| |
| 🔒 RELIABILITY |
| Self-healing, always available |
| |
| ⚡ SPEED |
| Starts in seconds |
| |
| 📦 PORTABILITY |
| Works on any computer |
| |
| 💰 EFFICIENT |
| Uses fewer resources |
| |
| 🔧 DEVOPS |
| Enables CI/CD pipelines |
| |
| ALL BECAUSE OF CONTAINERS & KUBERNETES! 🎉 |
| |
+--------------------------------------------------+
Containers and Kubernetes have many benefits. They provide consistency, scalability, reliability, speed, portability, resource efficiency, and DevOps enablement.
Containers, Kubernetes, and DevOps work together to help teams build and run software faster and more reliably. Containers package software, Kubernetes manages it, and DevOps provides the culture.
These three things work together to make modern software development possible. Understanding how they connect is important for any DevOps engineer.
Imagine you are building a house. DevOps is the team of people working together. Containers are the pre-built rooms that you can move anywhere. Kubernetes is the manager that makes sure all the rooms are in the right place and working properly.
A company uses DevOps practices. They use Docker to package their app. They use Kubernetes to run it. They can deploy new versions multiple times a day with zero downtime.
Your school uses a system where teachers work together (DevOps), lessons are prepared in advance (containers), and a schedule manages everything (Kubernetes).
Your family works together to manage the household (DevOps). You have pre-planned meals (containers). A chore schedule manages everything (Kubernetes).
A Nigerian company uses DevOps, containers, and Kubernetes. Developers work together, apps are packaged in containers, and Kubernetes manages them. They can deliver new features to customers very quickly.
CONTAINERS + KUBERNETES + DEVOPS
+--------------------------------------------------+
| |
| DEVOPS (Culture) |
| +-------------------------------------------+ |
| | Collaboration, automation, continuous | |
| +-------------------------------------------+ |
| | |
| V |
| CONTAINERS (Packaging) |
| +-------------------------------------------+ |
| | Docker packages the app | |
| | Runs the same everywhere | |
| +-------------------------------------------+ |
| | |
| V |
| KUBERNETES (Management) |
| +-------------------------------------------+ |
| | Scales, heals, updates containers | |
| | Automates everything | |
| +-------------------------------------------+ |
| | |
| V |
| FAST, RELIABLE SOFTWARE DELIVERY! 🚀 |
| |
+--------------------------------------------------+
Containers, Kubernetes, and DevOps work together. DevOps provides the culture, containers package the software, and Kubernetes manages it. Together, they enable fast, reliable software delivery.
In this lesson, we will review everything we have learned about containers, Docker, and Kubernetes. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use Docker to package their app and Kubernetes to run it. Their software is consistent, scalable, and reliable.
Your class has learned about containers and Kubernetes. They understand how packaging and managing software works.
Your family has learned about containers and Kubernetes. They understand the importance of consistency and automation.
A Nigerian developer has learned all these concepts. They can now use containers and Kubernetes to build and run scalable applications.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 Containers = Software that runs everywhere |
| 📌 Docker = Tool for containers |
| 📌 Image = Blueprint, Container = Running copy |
| 📌 Dockerfile = Recipe for building images |
| 📌 Kubernetes = Container manager |
| 📌 Pod = Smallest unit in Kubernetes |
| 📌 Deployment = Manages pods |
| 📌 Service = Access to pods |
| 📌 Namespace = Organizes resources |
| 📌 Benefits = Consistent, scalable, reliable |
| 📌 Works with DevOps for fast delivery |
| |
| YOU ARE NOW A CONTAINER & KUBERNETES BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about containers, Docker, and Kubernetes. These tools help teams package and run software consistently and reliably. They are a core part of modern DevOps.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Container | A package that contains everything a program needs to run |
| Docker | The most popular tool for creating and running containers |
| Docker Image | A blueprint for a container |
| Docker Container | A running instance of an image |
| Dockerfile | A text file with instructions to build an image |
| Kubernetes (K8s) | A tool that manages containers automatically |
| Pod | The smallest unit in Kubernetes, a group of containers |
| Deployment | Manages pods and handles scaling and updates |
| Service | A way to access pods and load balance traffic |
| Namespace | A way to organize Kubernetes resources |
| Control Plane | The brain of Kubernetes |
| Node | A computer that runs containers in Kubernetes |
| Orchestration | Automated management of containers |
| Scaling | Adding or removing containers based on demand |
| Self-healing | Restarting failed containers automatically |
| Rolling Update | Updating containers without downtime |
| Registry | A place to store and share Docker images |
Here are the most important concepts from this module. These are the big ideas that will help you understand containers and Kubernetes.
Containers make software portable. A container contains everything a program needs to run. It runs the same way on any computer. This solves the "works on my machine" problem.
Docker is the most popular container tool. Docker makes it easy to create, run, and share containers. It uses images (blueprints) and containers (running instances).
Kubernetes manages containers automatically. When you have many containers, Kubernetes helps you manage them. It scales, heals, and updates containers automatically.
Kubernetes has a clear architecture. The control plane is the brain. Nodes are computers that run pods. Services, deployments, and namespaces help organize everything.
Containers and Kubernetes enable DevOps. They work together to enable fast, reliable software delivery. DevOps provides the culture, containers package the software, and Kubernetes manages it.
Benefits include consistency and scalability. Containers and Kubernetes make software consistent, scalable, reliable, and fast. They are used by almost every modern software company.
Let us look at how to use Docker and Kubernetes in simple steps:
First, install Docker on your computer. Go to docker.com and download Docker Desktop for your operating system.
Create a file called Dockerfile. This file contains instructions to build your image. It says what base image to use, what files to copy, and what commands to run.
Run docker build -t myapp . to build the image from your Dockerfile. The image will be called "myapp."
Run docker run myapp to start a container from your image. Your app is now running in a container!
To use Kubernetes, you need a cluster. You can use Minikube for learning, or use a cloud provider like AWS EKS, Azure AKS, or Google GKE.
Create a deployment file that says how many pods to run and what image to use. Apply it with kubectl apply -f deployment.yaml.
Create a service file that exposes your app. Apply it with kubectl apply -f service.yaml. Now your app is accessible!
STEP-BY-STEP: DOCKER & KUBERNETES
Step 1: INSTALL DOCKER
+-------------------+
| docker.com |
+-------------------+
|
V
Step 2: WRITE DOCKERFILE
+-------------------+
| FROM python:3.9 |
| COPY . . |
| CMD python app.py|
+-------------------+
|
V
Step 3: BUILD IMAGE
+-------------------+
| docker build -t |
| myapp . |
+-------------------+
|
V
Step 4: RUN CONTAINER
+-------------------+
| docker run myapp |
+-------------------+
|
V
Step 5: CREATE CLUSTER
+-------------------+
| Minikube / Cloud |
+-------------------+
|
V
Step 6: CREATE DEPLOYMENT
+-------------------+
| kubectl apply -f |
| deployment.yaml |
+-------------------+
|
V
Step 7: CREATE SERVICE
+-------------------+
| kubectl apply -f |
| service.yaml |
+-------------------+
An e-commerce company uses Docker and Kubernetes. They have a Dockerfile for their website. They build images and push them to a registry. They use Kubernetes to run the images. During peak shopping seasons, Kubernetes automatically scales up to handle traffic.
A mobile app team uses containers for their backend. They use Docker to package the backend. They use Kubernetes to run it. They can deploy new versions with zero downtime using rolling updates.
A bank uses Kubernetes to manage their microservices. Each service is a container. Kubernetes manages all the containers. If a service fails, Kubernetes restarts it automatically. This makes the system very reliable.
Flutterwave uses Docker and Kubernetes to run their payment platform. They have many containers running. Kubernetes manages them automatically. This helps them handle millions of transactions every day.
Paystack uses containers for their payment processing. They use Docker to package their services. They use Kubernetes to manage them. This makes their system reliable and scalable.
A Nigerian tech startup uses Docker and Kubernetes. They have a microservices architecture. Each service is a container. Kubernetes manages all the containers. They can deploy new features quickly and safely.
You pack your lunch in a lunchbox. The lunchbox contains everything you need for lunch — food, utensils, napkin. You can eat lunch anywhere because everything is in the lunchbox. A container is like that lunchbox for software.
You have a LEGO set with instructions. The instructions tell you how to build the castle. Dockerfile is like those instructions. The castle you build is like a container. The instructions are like a Dockerfile.
You have a toy factory (Kubernetes). The factory makes toys (containers). If a toy breaks, the factory makes a new one (self-healing). If more children want toys, the factory makes more (scaling). Kubernetes is like that toy factory.
Your family has a recipe book. Each recipe is like a Dockerfile. When you cook, you follow the recipe. The food you make is like a container.
Your school has a schedule. It tells you which classes to take. A Kubernetes deployment is like that schedule — it tells Kubernetes what to run.
Your classroom has students and desks. Each desk is like a pod. Students sit at desks. If a student leaves, another student can sit there. Pods are like desks for containers.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about containers, Docker, and Kubernetes. Here are some tips to support their learning:
Mistake 1: Forgetting to use .dockerignore.
When you build a Docker image, all files in the directory are included. Use a .dockerignore file to exclude unnecessary files. This makes images smaller and faster.
Mistake 2: Using the latest tag for everything.
Using "latest" can cause problems because you do not know which version you are running. Use specific version numbers instead.
Mistake 3: Not using Kubernetes for production.
Kubernetes is great for production. It provides scaling, self-healing, and rolling updates. Use it for your production workloads.
Mistake 4: Making containers too large.
Large containers are slower to start and use more resources. Keep your containers small by using small base images and removing unnecessary files.
Mistake 5: Not using health checks.
Kubernetes uses health checks to know if a container is working. Without them, Kubernetes cannot restart failing containers.
Mistake 6: Running as root.
Running containers as root is a security risk. Use a non-root user in your containers for better security.
Use small base images.
Choose a small base image like Alpine Linux. This keeps your containers small and fast.
Use specific version tags.
Use specific version numbers for your images. For example, myapp:1.0.0 instead of latest.
Use .dockerignore.
Create a .dockerignore file to exclude unnecessary files. This makes your images smaller and builds faster.
Use health checks.
Add health checks to your containers. This helps Kubernetes know if your containers are working properly.
Use namespaces to organize.
Use different namespaces for different environments (dev, test, prod). This keeps resources organized and secure.
Use deployments for management.
Use Kubernetes deployments to manage your pods. Deployments provide scaling, rolling updates, and rollbacks.
Run as non-root user.
Run your containers as a non-root user for better security. Create a user in your Dockerfile.
CONTAINER VS VIRTUAL MACHINE
CONTAINER:
+--------------------------------------------------+
| App 1 │ App 2 │ App 3 |
| Docker Engine |
| Host Operating System |
| Hardware |
+--------------------------------------------------+
| Lightweight, fast, shares OS |
+--------------------------------------------------+
VIRTUAL MACHINE:
+--------------------------------------------------+
| App 1 │ App 2 │ App 3 |
| Guest OS │ Guest OS │ Guest OS |
| Hypervisor |
| Host Operating System |
| Hardware |
+--------------------------------------------------+
| Heavy, slow, each has its own OS |
+--------------------------------------------------+
DOCKER ARCHITECTURE
+--------------------------------------------------+
| DOCKER CLIENT |
| +-------------------------------------------+ |
| | docker build | |
| | docker run | |
| | docker push | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER DAEMON |
| +-------------------------------------------+ |
| | Builds images | |
| | Runs containers | |
| | Manages resources | |
| +-------------------------------------------+ |
| | |
| V |
| DOCKER REGISTRY |
| +-------------------------------------------+ |
| | Stores and shares images | |
| +-------------------------------------------+ |
+--------------------------------------------------+
KUBERNETES ARCHITECTURE
+--------------------------------------------------+
| CONTROL PLANE |
| +-------------------------------------------+ |
| | API Server │ Scheduler │ Controller | |
| | etcd | |
| +-------------------------------------------+ |
| | |
| V |
| NODE 1 |
| +-------------------------------------------+ |
| | Pod 1 │ Pod 2 │ Pod 3 | |
| +-------------------------------------------+ |
| | |
| V |
| NODE 2 |
| +-------------------------------------------+ |
| | Pod 1 │ Pod 2 │ Pod 3 | |
| +-------------------------------------------+ |
| | |
| V |
| NODE 3 |
| +-------------------------------------------+ |
| | Pod 1 │ Pod 2 │ Pod 3 | |
| +-------------------------------------------+ |
+--------------------------------------------------+
| Aspect | Containers | Virtual Machines |
|---|---|---|
| Size | Small (MBs) | Large (GBs) |
| Startup Time | Seconds | Minutes |
| Resource Usage | Low | High |
| OS | Shares host OS | Each has its own OS |
| Portability | Very portable | Portable but heavier |
| Management | Kubernetes, Docker | VMware, VirtualBox |
| Aspect | Docker Image | Docker Container |
|---|---|---|
| What It Is | A blueprint | A running instance |
| State | Static (not running) | Dynamic (running) |
| Can Be Modified | No (read-only) | Yes (while running) |
| Analogy | A recipe | A baked cake |
| Storage | In a registry | On a computer |
| Component | Purpose | Analogy |
|---|---|---|
| Pod | Holds containers | A room |
| Deployment | Manages pods | A manager |
| Service | Exposes pods | A door |
| Namespace | Organizes resources | A folder |
| Node | Runs pods | A computer |
| Control Plane | Manages everything | The brain |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 6 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Containers are packages that contain everything a program needs to run. They run the same way everywhere, solving the "works on my machine" problem. Containers are lightweight, fast, and portable.
Docker is the most popular tool for creating and running containers. It uses images (blueprints) and containers (running instances). Dockerfiles are recipes for building images.
Kubernetes is a tool that manages containers automatically. It scales containers, heals failed ones, and updates without downtime. It is like a ship captain for a fleet of containers.
Kubernetes has a control plane (brain) and nodes (computers). Pods are the smallest unit. Deployments manage pods. Services expose pods. Namespaces organize resources.
They provide consistency, scalability, reliability, speed, portability, resource efficiency, and DevOps enablement. They are used by almost every modern software company.
You have now completed Module 6! You are ready to move on to Module 7, where you will learn about Monitoring, Logging, and Observability. Keep up the great work!
Q1: What is a container?
A: A container is a package that contains everything a program needs to run. It runs the same way everywhere.
Q2: What is Docker?
A: Docker is the most popular tool for creating and running containers. It makes containers easy to use.
Q3: What is the difference between a Docker image and a container?
A: A Docker image is a blueprint. A Docker container is a running instance of that blueprint.
Q4: What is a Dockerfile?
A: A Dockerfile is a text file with instructions to build a Docker image. It is like a recipe.
Q5: What is Kubernetes?
A: Kubernetes is a tool that manages containers automatically. It scales, heals, and updates them.
Q6: What is a pod in Kubernetes?
A: A pod is the smallest unit in Kubernetes. It is a group of one or more containers.
Q7: What is a deployment in Kubernetes?
A: A deployment manages pods and handles scaling and updates.
Q8: What is a service in Kubernetes?
A: A service is a way to access pods and load balance traffic.
Q9: What are the benefits of containers and Kubernetes?
A: They provide consistency, scalability, reliability, speed, portability, efficiency, and DevOps enablement.
Q10: Are containers and Kubernetes used in Nigeria?
A: Yes, many Nigerian companies use containers and Kubernetes to build scalable and reliable applications.
What is a container?
Answer: A container is a package that contains everything a program needs to run.
What is Docker?
Answer: Docker is the most popular tool for creating and running containers.
What is the difference between a Docker image and a Docker container?
Answer: A Docker image is a blueprint. A Docker container is a running instance of the image.
What is a Dockerfile?
Answer: A Dockerfile is a text file with instructions to build a Docker image.
What is Kubernetes?
Answer: Kubernetes is a tool that manages containers automatically.
What is a pod in Kubernetes?
Answer: A pod is the smallest unit in Kubernetes. It is a group of containers.
What is a deployment in Kubernetes?
Answer: A deployment manages pods, scaling, and updates.
What is a service in Kubernetes?
Answer: A service is a way to access pods and load balance traffic.
What is a namespace in Kubernetes?
Answer: A namespace organizes Kubernetes resources.
Name two benefits of using containers.
Answer: Consistency and portability. (Other answers: scalability, reliability, speed, efficiency.)
What is orchestration in Kubernetes?
Answer: Orchestration is the automated management of containers.
What is self-healing in Kubernetes?
Answer: Self-healing is restarting failed containers automatically.
What is a rolling update?
Answer: A rolling update updates containers without downtime.
Is Docker used in Nigeria?
Answer: Yes, many Nigerian companies use Docker.
What command starts a container from an image?
Answer: docker run
Fill in the blanks with the correct words from the list:
Word list: container, Docker, image, Kubernetes, pod, deployment, service, namespace, Dockerfile, orchestration, scaling, self-healing
A __________ is a package that contains everything a program needs to run.
Answer: container
__________ is the most popular tool for creating and running containers.
Answer: Docker
A Docker __________ is a blueprint for a container.
Answer: image
A __________ is a text file with instructions to build an image.
Answer: Dockerfile
__________ is a tool that manages containers automatically.
Answer: Kubernetes
A __________ is the smallest unit in Kubernetes.
Answer: pod
A __________ manages pods and handles scaling.
Answer: deployment
A __________ is a way to access pods and load balance traffic.
Answer: service
A __________ organizes Kubernetes resources.
Answer: namespace
The automated management of containers is called __________.
Answer: orchestration
Adding or removing containers based on demand is called __________.
Answer: scaling
Restarting failed containers automatically is called __________.
Answer: self-healing
Write True or False for each statement:
Containers run the same way everywhere.
Answer: True
Docker is the only tool for containers.
Answer: False (There are other tools like Podman, but Docker is the most popular.)
A Docker image is a running instance.
Answer: False (An image is a blueprint. A container is a running instance.)
A Dockerfile is a recipe for building images.
Answer: True
Kubernetes manages containers automatically.
Answer: True
A pod is the largest unit in Kubernetes.
Answer: False (A pod is the smallest unit.)
Deployments manage pods and scaling.
Answer: True
Services make pods accessible.
Answer: True
Namespaces organize Kubernetes resources.
Answer: True
Containers are larger than virtual machines.
Answer: False (Containers are smaller than virtual machines.)
Kubernetes can scale containers automatically.
Answer: True
Rolling updates cause downtime.
Answer: False (Rolling updates happen without downtime.)
Docker is used in Nigeria.
Answer: True
Kubernetes was created by Google.
Answer: True
The command "docker run" starts a container.
Answer: True
Choose the correct answer for each question:
What is a container?
A) A type of computer
B) A package that contains everything a program needs to run
C) A programming language
D) A video game
Answer: B
What is Docker?
A) A video game
B) A programming language
C) The most popular tool for creating and running containers
D) A type of computer
Answer: C
What is the difference between a Docker image and a container?
A) They are the same thing
B) An image is a blueprint; a container is a running instance
C) An image is running; a container is not
D) There is no difference
Answer: B
What is a Dockerfile?
A) A type of container
B) A text file with instructions to build an image
C) A Docker image
D) A programming language
Answer: B
What is Kubernetes?
A) A type of container
B) A programming language
C) A tool that manages containers automatically
D) A video game
Answer: C
What is a pod in Kubernetes?
A) The largest unit in Kubernetes
B) The smallest unit in Kubernetes, a group of containers
C) A type of service
D) A programming language
Answer: B
What does a deployment do?
A) Manages pods and scaling
B) Exposes pods to users
C) Organizes resources
D) Runs containers
Answer: A
What does a service do?
A) Manages pods
B) Exposes pods and load balances traffic
C) Organizes resources
D) Builds images
Answer: B
What is a namespace in Kubernetes?
A) A way to organize resources
B) A type of pod
C) A programming language
D) A type of service
Answer: A
What is orchestration?
A) The automated management of containers
B) A type of container
C) A programming language
D) A type of service
Answer: A
What is self-healing?
A) Restarting failed containers automatically
B) A type of service
C) A programming language
D) A type of pod
Answer: A
What is a rolling update?
A) Updating containers with downtime
B) Updating containers without downtime
C) Deleting all containers
D) A type of service
Answer: B
Which command starts a container from an image?
A) docker build
B) docker run
C) docker stop
D) docker rm
Answer: B
Is Docker used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
Who created Kubernetes?
A) Microsoft
B) Amazon
C) Google
D) Apple
Answer: C
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Container | A. A tool that manages containers automatically |
| 2. Docker | B. The smallest unit in Kubernetes |
| 3. Docker Image | C. A text file with instructions to build an image |
| 4. Dockerfile | D. A package that contains everything a program needs |
| 5. Kubernetes | E. A way to access pods and load balance traffic |
| 6. Pod | F. A blueprint for a container |
| 7. Deployment | G. A way to organize Kubernetes resources |
| 8. Service | H. The most popular tool for containers |
| 9. Namespace | I. Manages pods and scaling |
| 10. Orchestration | J. The automated management of containers |
Answers:
What is a container and why is it useful?
Answer: A container is a package that contains everything a program needs to run. It is useful because it makes software run the same way everywhere, solving the "works on my machine" problem. Containers are lightweight, fast, and portable.
Explain the difference between a Docker image and a Docker container.
Answer: A Docker image is a blueprint or recipe. It contains everything needed to run the software but is not running. A Docker container is a running instance of an image. You can run many containers from one image.
What is Kubernetes and what does it do?
Answer: Kubernetes is a tool that manages containers automatically. It scales containers based on demand, heals failed containers, updates containers without downtime, and load balances traffic. It is like a ship captain for a fleet of containers.
Describe the main components of Kubernetes architecture.
Answer: The control plane is the brain of Kubernetes. Nodes are computers that run containers. Pods are the smallest unit, containing one or more containers. Deployments manage pods and scaling. Services expose pods to users. Namespaces organize resources.
How do containers and Kubernetes support DevOps?
Answer: Containers and Kubernetes are core parts of DevOps. Containers package software so it runs consistently everywhere. Kubernetes manages containers automatically. Together with DevOps culture, they enable fast, reliable software delivery. They make CI/CD pipelines work smoothly.
A company has a problem. Their app works on the developer's computer but crashes on the server. They spend hours trying to fix it.
Question: How could containers help this company?
Answer: Containers could help by packaging the app with everything it needs to run. The app would run the same way on the developer's computer and on the server. This would eliminate the "works on my machine" problem.
A Nigerian e-commerce company has a huge traffic spike during a sale. Their servers cannot handle the load and the website crashes.
Question: How could Kubernetes help this company?
Answer: Kubernetes could help by automatically scaling up the number of containers when traffic increases. It would start more containers to handle the load. When traffic decreases, it would scale down to save resources. This would keep the website running during the sale.
A Nigerian startup wants to use containers and Kubernetes. They have a web app with 3 microservices. They want to deploy updates without downtime.
Question: How can they use Kubernetes to achieve zero-downtime updates?
Answer: They can use Kubernetes rolling updates. They create a deployment for each microservice. When they need to update, they change the image version in the deployment. Kubernetes automatically updates the pods one by one, ensuring zero downtime. If there is a problem, they can roll back easily.
Instructions:
Instructions:
Why do you think containers are better than virtual machines?
Discuss with your classmates and share your ideas.
Have you ever had a problem where something worked on one computer but not another? How did it make you feel?
Share your experiences and thoughts.
What are some other situations where packaging everything together is helpful?
Think about school, home, and other activities.
Do you think Kubernetes is necessary for all projects?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from containers and Kubernetes?
Share examples of companies in Nigeria.
What do you think is the most important part of Kubernetes?
Explain why you think so.
Do you think containers are easy to learn? Why or why not?
Share your thoughts.
What is the most important thing you learned about containers and Kubernetes today?
Share with the class.
Goal: Create a simple guide to teach beginners about containers, Docker, and Kubernetes.
Instructions:
Goal: Learn about real-world container and Kubernetes practice.
Instructions:
Scenario:
You are a container architect at a Nigerian company. The company has 15 developers working on a large web application. They want to use containers and Kubernetes to improve their deployment process.
The company has:
Challenge: Create a complete container and Kubernetes implementation plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 6: "Containerization & Orchestration." You now understand how containers package software and how Kubernetes manages them automatically.
In Module 7, you will learn:
Before you start Module 7, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 7! 🚀
© 2026 Certified DevOps Engineer Course • Module 6: Containerization & Orchestration (Docker & Kubernetes)
Welcome to Module 7 of our Certified DevOps Engineer course! This module is called "Monitoring, Logging & Observability: Seeing What's Happening in Your Systems."
In this module, we will learn about monitoring, logging, and observability — three important practices that help us understand what is happening in our software systems. They are like the dashboard, gauges, and cameras in a car that tell you how the car is doing.
Think of monitoring like the speedometer in a car. It tells you how fast you are going. Logging is like the car's black box that records everything that happens. Observability is like being able to look under the hood and understand why the car is doing what it is doing.
Hello and welcome back! In Module 1, we learned about DevOps. In Module 2, we learned about Git. In Module 3, we learned about Continuous Integration. In Module 4, we learned about Continuous Delivery. In Module 5, we learned about Infrastructure as Code. In Module 6, we learned about containers and Kubernetes. Now, in Module 7, we are going to learn about Monitoring, Logging, and Observability.
Imagine you are driving a car. You have a dashboard with gauges (monitoring), a GPS that tracks your route (logging), and the ability to open the hood and check the engine (observability). These three things help you understand how your car is doing and fix problems.
Software systems are the same. We need to know if they are working properly, what they are doing, and why they might be having problems. Monitoring, logging, and observability give us this information.
In this module, we will learn all about these practices — what they are, why they are important, and what tools we use. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover how to see what is happening in our software systems!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company called "QuickPay." They built a payment app that helped people send money to each other.
The app was very popular. Millions of people used it every day. But the company had a big problem. They did not know when something went wrong. Their app would crash, and they would only find out when customers started calling to complain.
One day, a very important customer called. He said, "Your app is not working! I cannot send money to my family!" The team scrambled to fix the problem. But they had no idea what was wrong. They had to guess and check, which took hours.
The team was very frustrated. They knew they needed a way to see what was happening in their app. That is when they discovered monitoring, logging, and observability.
They set up Prometheus to collect metrics about their app. They used Grafana to create dashboards that showed everything in real-time. They set up logs to record every event. And they used alerts to notify them immediately when something went wrong.
Now, when something breaks, the team knows immediately. They get an alert on their phones. They look at the dashboard and see exactly what is wrong. They check the logs to see what happened. They fix the problem in minutes, not hours.
QuickPay became the most reliable payment app in Nigeria. Customers loved them. And it was all because they could see what was happening in their systems.
This story shows us how important it is to see what is happening in our software. Monitoring, logging, and observability make this possible. Let us learn more about these amazing tools!
Monitoring is the practice of watching your systems to make sure they are working properly. It is like checking the gauges on your car dashboard to see if everything is okay.
Monitoring is important because it helps you know if your software is working. Without monitoring, you would not know when something is wrong until users tell you. Monitoring finds problems early.
Imagine you are a doctor. You check your patient's heartbeat, blood pressure, and temperature. These are all "monitoring" of the patient's health. Monitoring software is the same — you check its "vital signs" to see if it is healthy.
A company monitors their website. They watch the response time and error rate. If the response time gets too slow, they know they need to add more servers.
Your teacher monitors the class. They check if students are paying attention, if the lesson is going well, and if anyone needs help. Monitoring software does the same for computer systems.
Your family monitors the house. You check if the lights are on, if the doors are locked, and if the temperature is comfortable. Monitoring software does the same for servers.
A Nigerian bank monitors their mobile app. They check if the app is available, how fast it is, and if there are any errors. This helps them provide reliable service to their customers.
WHAT IS MONITORING?
+--------------------------------------------------+
| MONITORING (Like a car dashboard) |
| |
| +-------------------------------------------+ |
| | Speed: 60 km/h | |
| | Fuel: 75% | |
| | Engine: Normal | |
| | Temperature: 90°C | |
| +-------------------------------------------+ |
| |
| MONITORING SOFTWARE: |
| +-------------------------------------------+ |
| | CPU: 45% | |
| | Memory: 60% | |
| | Disk: 80% | |
| | Response Time: 200ms | |
| | Errors: 0 | |
| | Uptime: 99.9% | |
| +-------------------------------------------+ |
| |
| 🔑 Monitoring = Checking system health! |
| |
+--------------------------------------------------+
Monitoring is the practice of watching your systems to make sure they are working properly. It checks things like CPU, memory, response time, and errors. It is like looking at the dashboard of a car.
Why we need monitoring: We need monitoring because software systems can break without warning. Monitoring gives us early warning so we can fix problems before they affect users.
Monitoring helps us keep our software running smoothly. It saves time, money, and protects our reputation. Without monitoring, we are flying blind.
Imagine you are driving a car that has no dashboard. You cannot see how fast you are going, how much fuel you have, or if the engine is overheating. You could break down at any time without warning. Monitoring is like having a dashboard for your software!
| Problem | What It Means | Monitoring Solution |
|---|---|---|
| Unknown Issues | You do not know when something is wrong | Monitoring shows you in real-time |
| Slow Response | It takes hours to find and fix problems | Monitoring helps you find problems instantly |
| Unhappy Users | Users are frustrated by broken software | Monitoring prevents issues from affecting users |
| Lost Money | Downtime costs money | Monitoring reduces downtime |
| Blame Game | No one knows what caused the problem | Monitoring provides evidence |
A company without monitoring had a server crash. They only found out when customers started calling. It took 4 hours to fix. With monitoring, they would have been alerted in seconds and fixed it in minutes.
Your school does not have a bell system. Teachers do not know when class starts. There is chaos. Monitoring is like having a bell system for your software — it tells you when something is wrong.
Your family does not have a smoke detector. A fire could start and no one would know. Monitoring is like a smoke detector for your software.
A Nigerian e-commerce company did not have monitoring. Their website went down during a big sale. They lost millions of naira in sales. After adding monitoring, they never had a problem like that again.
WHY WE NEED MONITORING
WITHOUT MONITORING:
+--------------------------------------------------+
| ❌ No idea what is happening |
| ❌ Problems found late |
| ❌ Slow to fix problems |
| ❌ Unhappy users |
| ❌ Lost money |
+--------------------------------------------------+
WITH MONITORING:
+--------------------------------------------------+
| ✅ Real-time visibility |
| ✅ Problems found immediately |
| ✅ Fast to fix problems |
| ✅ Happy users |
| ✅ Save money |
+--------------------------------------------------+
We need monitoring because it gives us early warning when something goes wrong. It helps us fix problems quickly before they affect users. Without monitoring, we are flying blind.
Metrics are numbers that tell us about the health and performance of our systems. They are like the numbers on a dashboard — speed, fuel, temperature.
Metrics are important because they give us objective, measurable information about our systems. They help us see trends, spot problems, and make decisions.
Imagine you are tracking your fitness. You measure your weight, your steps, your heart rate. These are your fitness metrics. Software metrics are the same — they are numbers that tell us how our software is doing.
| Type | What It Measures | Example |
|---|---|---|
| Counter | Count of events that happen | Number of requests, errors, users |
| Gauge | A current value that goes up and down | CPU usage, memory usage, temperature |
| Histogram | Distribution of values | Response times, request sizes |
| Summary | Statistical summary of values | Average, median, percentile |
A company tracks these metrics: requests per second, average response time, and error rate. If the error rate goes above 1%, they investigate.
Your class tracks metrics for a project: number of tasks completed, time spent, and quality score. These metrics help you see how you are doing.
Your family tracks metrics: grocery spending, electricity usage, and chores completed. These metrics help you manage your household.
A Nigerian company tracks metrics for their app: daily active users, transactions per day, and average transaction time. These metrics help them understand their business.
METRICS
+--------------------------------------------------+
| METRICS (Numbers that tell us about health) |
| |
| COUNTER (Counts events): |
| +-------------------------------------------+ |
| | Total Requests: 1,234,567 | |
| | Total Errors: 12,345 | |
| | Total Users: 45,678 | |
| +-------------------------------------------+ |
| |
| GAUGE (Current value): |
| +-------------------------------------------+ |
| | CPU Usage: 45% | |
| | Memory Usage: 60% | |
| | Current Users: 1,234 | |
| +-------------------------------------------+ |
| |
| HISTOGRAM (Distribution): |
| +-------------------------------------------+ |
| | Response Times: | |
| | ≤ 10ms: 80% | |
| | ≤ 50ms: 15% | |
| | ≤ 100ms: 4% | |
| | > 100ms: 1% | |
| +-------------------------------------------+ |
| |
| 🔑 Metrics = Numbers that matter! |
| |
+--------------------------------------------------+
Metrics are numbers that tell us about the health of our systems. They include things like request rate, error rate, latency, and resource usage. Metrics help us see what is happening.
Prometheus is a popular tool for collecting and storing metrics. It is like a super-smart data collector that gathers numbers from your systems and stores them for you.
Prometheus is important because it is one of the most popular monitoring tools in the world. It is used by thousands of companies, including many in Nigeria.
Imagine you have a robot that goes around collecting data from all your sensors. It checks the temperature, the speed, the fuel level. Then it writes all the data down in a notebook. Prometheus is like that robot for your software systems!
A company uses Prometheus to collect metrics from their Kubernetes cluster. Prometheus gathers CPU, memory, and network metrics from every container. They can see the health of their entire system.
Your school has a robot that collects data from every classroom. It checks how many students are present, how much noise there is, and the temperature. Prometheus is like that robot but for servers.
Your family has a smart home system that collects data from all the sensors. It checks the temperature, the lights, and the locks. Prometheus is like that smart home system for software.
A Nigerian fintech uses Prometheus to monitor their payment system. They collect metrics on transaction success rates, response times, and system resources. This helps them provide reliable service.
PROMETHEUS
+--------------------------------------------------+
| PROMETHEUS (Data Collector) |
| |
| +-------------------------------------------+ |
| | "Pull" metrics from systems | |
| | Store in time series database | |
| | Query with PromQL | |
| | Send alerts when problems found | |
| +-------------------------------------------+ |
| | |
| V |
| SYSTEMS TO MONITOR: |
| +-------------------------------------------+ |
| | Server 1: CPU 45%, Memory 60% | |
| | Server 2: CPU 30%, Memory 45% | |
| | App 1: Requests 1,234/s | |
| | Database: Queries 567/s | |
| +-------------------------------------------+ |
| |
| 🔑 Prometheus = Open source monitoring! |
| |
+--------------------------------------------------+
Prometheus is a popular tool for collecting and storing metrics. It pulls data from systems, stores it in a time series database, and allows you to query and alert on the data. It is open source and widely used.
Grafana is a tool that creates beautiful dashboards from your metrics. It takes the numbers from Prometheus and turns them into graphs, charts, and visualizations that are easy to understand.
Grafana is important because it makes monitoring data easy to see and understand. A picture is worth a thousand words, and Grafana turns numbers into pictures.
Imagine you have a lot of data in a spreadsheet. It is just numbers in rows and columns. It is hard to see patterns. Grafana is like a tool that turns that spreadsheet into colorful graphs and charts. Suddenly, you can see what is happening!
A company uses Grafana to visualize their Prometheus metrics. They have a dashboard that shows CPU usage, memory usage, request rate, and error rate. The team can see at a glance if everything is healthy.
Your school tracks student performance. Instead of looking at spreadsheets, they use a dashboard that shows grades, attendance, and progress in colorful charts. Grafana is like that dashboard for software.
Your family tracks expenses. Instead of a boring spreadsheet, they use a dashboard that shows spending in colorful pie charts and bar graphs. Grafana is like that dashboard for metrics.
A Nigerian company uses Grafana to monitor their app. Their dashboard shows transactions per minute, response times, and error rates. They can see the health of their system at a glance.
GRAFANA
+--------------------------------------------------+
| GRAFANA DASHBOARD |
| |
| +-------------------------------------------+ |
| | 📊 CPU Usage | |
| | ████████████████████░░░░ 80% | |
| +-------------------------------------------+ |
| +-------------------------------------------+ |
| | 📈 Request Rate | |
| | ╔═══════════════════════════╗ | |
| | ║ ██████████████████████ ║ 1,234/s | |
| | ╚═══════════════════════════╝ | |
| +-------------------------------------------+ |
| +-------------------------------------------+ |
| | 🔴 Error Rate | |
| | ██████████░░░░░░░░░░░░ 0.5% | |
| +-------------------------------------------+ |
| +-------------------------------------------+ |
| | ⏱️ Response Time | |
| | ████████████████████░░░░ 45ms | |
| +-------------------------------------------+ |
| |
| 🔑 Grafana = Beautiful dashboards! |
| |
+--------------------------------------------------+
Grafana is a tool that creates beautiful dashboards from metrics. It turns numbers into graphs and charts that are easy to understand. It works with many data sources including Prometheus.
Prometheus and Grafana together form a powerful monitoring stack. Prometheus collects and stores the data. Grafana visualizes it. They work together like a pair of best friends.
Together, they give you a complete monitoring solution. You can collect data, store it, visualize it, and alert on it. This is the standard monitoring setup used by thousands of companies.
Imagine you are a detective. Prometheus is your notebook where you write down all the clues. Grafana is your corkboard where you pin up the clues and see the big picture. Together, they help you solve the mystery!
| Component | What It Does | Analogy |
|---|---|---|
| Prometheus | Collects and stores metrics | A notebook for data |
| Grafana | Visualizes metrics on dashboards | A corkboard for visual clues |
| Together | Complete monitoring solution | A detective's investigation board |
A company sets up Prometheus to collect metrics from their servers. They connect Grafana to Prometheus. They create a dashboard that shows everything in real-time. The team can see the health of their systems at a glance.
Your class uses a notebook to record data (Prometheus) and a whiteboard to draw charts (Grafana). Together, you can see the full picture of your project.
Your family uses a spreadsheet to track expenses (Prometheus) and a chart to visualize spending (Grafana). Together, you can manage your budget better.
A Nigerian company uses Prometheus and Grafana. Prometheus collects metrics from their app. Grafana shows them on a dashboard. The team can see the health of their app in real-time.
PROMETHEUS + GRAFANA
+--------------------------------------------------+
| PROMETHEUS (Data Collector) |
| +-------------------------------------------+ |
| | Collects metrics from servers, apps, | |
| | containers, and other systems | |
| +-------------------------------------------+ |
| | |
| V |
| GRAFANA (Visualizer) |
| +-------------------------------------------+ |
| | Creates beautiful dashboards from data | |
| | Shows graphs, charts, and alerts | |
| +-------------------------------------------+ |
| | |
| V |
| TEAM CAN SEE THE BIG PICTURE! |
| +-------------------------------------------+ |
| | ✅ Real-time visibility | |
| | ✅ Quick problem detection | |
| | ✅ Better decision making | |
| +-------------------------------------------+ |
| |
| 🔑 Prometheus + Grafana = Monitoring power! |
| |
+--------------------------------------------------+
Prometheus and Grafana work together to provide a complete monitoring solution. Prometheus collects and stores data. Grafana visualizes it on beautiful dashboards. Together, they give you real-time visibility into your systems.
Logging is the practice of recording events that happen in your software. Logs are like a diary that records everything your software does.
Logging is important because it gives you a detailed record of what happened. When something goes wrong, logs help you figure out what happened and why.
Imagine you are a detective investigating a crime. You need to know what happened. You look at witness statements, security camera footage, and other evidence. Logs are like that evidence for your software.
A web app logs every request: who made the request, what they asked for, and how long it took. If something goes wrong, they can look at the logs to see what happened.
Your teacher keeps a log of attendance. It records who came to class and who was absent. This helps the teacher know who is missing. Logs do the same for software.
Your family keeps a log of who does the chores. It records who did what and when. This helps everyone know what has been done. Logs do the same for software.
A Nigerian bank logs every transaction. If a customer calls to complain about a transaction, the bank can look at the logs to see what happened.
LOGGING
+--------------------------------------------------+
| LOG FILE (Diary of events) |
| |
| [2026-07-15 10:00:01] INFO: User 123 logged in |
| [2026-07-15 10:00:05] INFO: User 123 viewed page |
| [2026-07-15 10:00:10] WARNING: Slow query took |
| 5 seconds |
| [2026-07-15 10:00:15] ERROR: Payment failed for |
| order 456 |
| [2026-07-15 10:00:20] DEBUG: Payment gateway |
| returned timeout |
| |
| Log Levels: |
| +-------------------------------------------+ |
| | DEBUG: Very detailed for debugging | |
| | INFO: General information | |
| | WARNING: Something might be wrong | |
| | ERROR: Something definitely went wrong | |
| | FATAL: Critical failure | |
| +-------------------------------------------+ |
| |
| 🔑 Logs = Evidence for your software! |
| |
+--------------------------------------------------+
Logging is the practice of recording events that happen in your software. Logs are like a diary that records everything your software does. They help you investigate problems and understand what happened.
The ELK Stack is a set of three tools for collecting, storing, and visualizing logs. ELK stands for Elasticsearch, Logstash, and Kibana.
The ELK Stack is important because it gives you a complete logging solution. You can collect logs from any source, store them, search them, and visualize them. It is the most popular logging stack in the world.
Imagine you have a huge library with millions of books. Elasticsearch is the library catalog that helps you find books quickly. Logstash is the librarian who collects books from everywhere. Kibana is the reading room where you can read and understand the books. Together, they help you manage all your logs!
| Component | What It Does | Analogy |
|---|---|---|
| Elasticsearch | Stores and indexes logs so they can be searched quickly | A library catalog |
| Logstash | Collects logs from various sources and sends them to Elasticsearch | A librarian |
| Kibana | Visualizes logs on dashboards | A reading room |
A company uses the ELK Stack to manage their logs. Logstash collects logs from all their servers. Elasticsearch stores and indexes them. Kibana provides a dashboard where the team can search and visualize the logs.
Your school has a library (Elasticsearch), a librarian (Logstash) who collects books from all classrooms, and a reading room (Kibana) where students can read. The ELK Stack is like that for logs.
Your family has a filing system (Elasticsearch), a person who collects documents (Logstash), and a desk (Kibana) where you organize them. The ELK Stack is like that for logs.
A Nigerian company uses the ELK Stack for logging. Logstash collects logs from their servers. Elasticsearch stores them. Kibana provides a dashboard for the team to search and analyze logs.
THE ELK STACK
+--------------------------------------------------+
| LOGSTASH (Collector) |
| +-------------------------------------------+ |
| | Collects logs from servers, apps, and | |
| | containers | |
| +-------------------------------------------+ |
| | |
| V |
| ELASTICSEARCH (Storage) |
| +-------------------------------------------+ |
| | Stores and indexes logs | |
| | Fast search capabilities | |
| +-------------------------------------------+ |
| | |
| V |
| KIBANA (Visualization) |
| +-------------------------------------------+ |
| | Creates dashboards from logs | |
| | Search and analyze logs | |
| +-------------------------------------------+ |
| |
| 🔑 ELK Stack = Complete logging solution! |
| |
+--------------------------------------------------+
The ELK Stack is a set of tools for logging. Elasticsearch stores and indexes logs. Logstash collects logs from various sources. Kibana visualizes logs on dashboards. Together, they provide a complete logging solution.
Observability is the ability to understand what is happening inside a system from the outside. It goes beyond monitoring and logging to help you understand why something is happening.
Observability is important because it helps you solve problems you have never seen before. Monitoring tells you something is wrong. Observability tells you why.
Imagine you are a doctor. Monitoring tells you that a patient has a fever. Logging tells you the patient's temperature history. Observability tells you why the patient has a fever — maybe it is an infection. Observability is about understanding the cause.
| Pillar | What It Is | Analogy |
|---|---|---|
| Metrics | Numbers about system health | Your temperature reading |
| Logs | Records of events | Your medical history |
| Traces | Records of requests through the system | A doctor's diagnosis |
A company has a slow payment system. Monitoring shows that response times are high. Logs show many errors. Traces show that a database query is slow. Observability helps them find the root cause.
A student is not doing well in class. Monitoring (grades) shows a problem. Logs (attendance, behavior) provide more information. Observability (understanding why) might reveal that the student is struggling with a specific subject.
Your house is too hot. Monitoring (thermometer) shows the temperature. Logs (thermostat settings) show what it is set to. Observability (checking the air conditioner) reveals the AC is broken.
A Nigerian company has a problem with their app. Monitoring shows errors. Logs show error messages. Tracing shows that a third-party service is slow. Observability helps them identify the root cause.
OBSERVABILITY
+--------------------------------------------------+
| OBSERVABILITY (Understanding WHY) |
| |
| MONITORING: |
| +-------------------------------------------+ |
| | "The system is slow!" | |
| +-------------------------------------------+ |
| | |
| V |
| LOGGING: |
| +-------------------------------------------+ |
| | "There are many errors!" | |
| +-------------------------------------------+ |
| | |
| V |
| TRACING: |
| +-------------------------------------------+ |
| | "The database query is slow!" | |
| +-------------------------------------------+ |
| | |
| V |
| OBSERVABILITY: |
| +-------------------------------------------+ |
| | "The database is missing an index!" | |
| | ✅ We know WHY! | |
| +-------------------------------------------+ |
| |
| 🔑 Observability = Understanding the cause! |
| |
+--------------------------------------------------+
Observability is the ability to understand why something is happening. It goes beyond monitoring and logging. It uses metrics, logs, and traces to help you find the root cause of problems.
Application Performance Monitoring (APM) is a type of monitoring that focuses on the performance of your applications. It tracks how fast your app is, how often it errors, and what users are experiencing.
APM is important because it helps you understand how your users experience your app. If your app is slow, users will leave. APM helps you keep your app fast and reliable.
Imagine you are a restaurant owner. You want to know how long customers wait for their food, how often orders are wrong, and if customers are happy. APM is like that for your app — it tracks how your app is performing for users.
A company uses APM to track their e-commerce app. They see that the checkout page is slow. They investigate and find that a database query is slow. They fix it and checkout becomes fast again.
Your teacher tracks how long it takes for students to complete tests. If a test takes too long, they adjust it. APM does the same for apps.
Your family tracks how long it takes to get ready in the morning. If it takes too long, you adjust your routine. APM does the same for apps.
A Nigerian company uses APM to monitor their mobile app. They track response times and error rates. They notice that the app is slow in some areas. They optimize it and users have a better experience.
APPLICATION PERFORMANCE MONITORING (APM)
+--------------------------------------------------+
| APM DASHBOARD |
| |
| +-------------------------------------------+ |
| | ⏱️ Average Response Time: 200ms | |
| | 🔴 Error Rate: 0.5% | |
| | 📊 Requests per second: 1,234 | |
| +-------------------------------------------+ |
| |
| Transaction Trace: |
| +-------------------------------------------+ |
| | User Request → API Gateway → Service A | |
| | → Service B → Database → Response | |
| | | |
| | Service A: 50ms | |
| | Service B: 100ms | |
| | Database: 50ms | |
| +-------------------------------------------+ |
| |
| 🔑 APM = Performance monitoring for apps! |
| |
+--------------------------------------------------+
APM is a type of monitoring that focuses on application performance. It tracks response time, error rate, and user experience. It helps you keep your app fast and reliable.
Alerting is the practice of sending notifications when something goes wrong. Incident response is the process of fixing the problem when an alert is triggered.
Alerting is important because it tells you immediately when something is wrong. Incident response is important because it gives you a plan for fixing problems quickly.
Imagine you are a firefighter. Alerting is like the fire alarm that tells you there is a fire. Incident response is like the plan you follow to put out the fire. Together, they help you respond to emergencies quickly.
A company has an alert that triggers when the error rate goes above 1%. When the alert fires, the team follows their incident response plan. They diagnose the problem, fix it, and restore service. Afterward, they review what happened to prevent it from happening again.
Your school has a fire alarm (alert) and a fire drill plan (incident response). When the alarm goes off, everyone follows the plan. This is like alerting and incident response for software.
Your family has a smoke detector (alert) and a fire escape plan (incident response). When the detector goes off, everyone follows the plan. This is like alerting and incident response for software.
A Nigerian company has alerts set up for their payment system. If the error rate goes above 0.5%, an alert is sent to the on-call engineer. They follow the incident response plan to fix the problem quickly.
ALERTING & INCIDENT RESPONSE
+--------------------------------------------------+
| ALERT TRIGGERED |
| +-------------------------------------------+ |
| | 🚨 Alert: Error rate is 2%! | |
| | Service: Payment System | |
| | Time: 10:05 AM | |
| +-------------------------------------------+ |
| | |
| V |
| INCIDENT RESPONSE PROCESS |
| +-------------------------------------------+ |
| | 1. Detect: Alert received | |
| | 2. Diagnose: What is wrong? | |
| | 3. Contain: Stop it from spreading | |
| | 4. Fix: Fix the root cause | |
| | 5. Recover: Restore service | |
| | 6. Review: Learn and improve | |
| +-------------------------------------------+ |
| | |
| V |
| SERVICE RESTORED! |
| +-------------------------------------------+ |
| | ✅ System is healthy again! | |
| +-------------------------------------------+ |
| |
| 🔑 Alerting + Response = Fast recovery! |
| |
+--------------------------------------------------+
Alerting sends notifications when something goes wrong. Incident response is the plan for fixing the problem. Together, they help you respond quickly and recover from problems.
Monitoring, logging, observability, and DevOps work together to help teams build and run reliable software. Monitoring tells you what is happening. Logging tells you what happened. Observability tells you why. DevOps provides the culture to act on this information.
These four things work together to make software reliable. Without them, teams are blind. With them, teams can see everything and respond quickly.
Imagine you are a doctor. Monitoring is like checking the patient's vital signs. Logging is like reading the patient's medical history. Observability is like running tests to find the cause. DevOps is like the team of doctors working together to treat the patient.
| Component | What It Does | Analogy |
|---|---|---|
| Monitoring | Tells you what is happening | Vital signs |
| Logging | Records what happened | Medical history |
| Observability | Explains why it happened | Medical tests |
| DevOps | Culture to act on information | The medical team |
A company uses monitoring, logging, observability, and DevOps together. Monitoring shows a problem. Logs provide details. Observability explains the cause. The DevOps team works together to fix it quickly.
Your school tracks student performance (monitoring), keeps records (logging), understands why students struggle (observability), and has teachers who help (DevOps). Together, they help students succeed.
Your family tracks expenses (monitoring), keeps receipts (logging), understands why you overspend (observability), and works together to budget (DevOps). Together, they help manage money.
A Nigerian company uses monitoring, logging, observability, and DevOps. They monitor their app, log everything, use observability to understand issues, and have a DevOps team to fix them. Their app is very reliable.
MONITORING + LOGGING + OBSERVABILITY + DEVOPS
+--------------------------------------------------+
| MONITORING: |
| +-------------------------------------------+ |
| | "The system is slow!" | |
| +-------------------------------------------+ |
| | |
| V |
| LOGGING: |
| +-------------------------------------------+ |
| | "There are many errors!" | |
| +-------------------------------------------+ |
| | |
| V |
| OBSERVABILITY: |
| +-------------------------------------------+ |
| | "The database query is slow!" | |
| +-------------------------------------------+ |
| | |
| V |
| DEVOPS: |
| +-------------------------------------------+ |
| | Team fixes the database query | |
| | System is fast again! | |
| +-------------------------------------------+ |
| |
| 🔑 Together they make software reliable! |
| |
+--------------------------------------------------+
Monitoring, logging, observability, and DevOps work together. Monitoring tells you what is happening. Logging records what happened. Observability explains why. DevOps provides the culture to act on the information. Together, they make software reliable.
In this lesson, we will review everything we have learned about monitoring, logging, and observability. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use Prometheus and Grafana for monitoring. They use the ELK Stack for logging. They have alerts set up. Their software is very reliable.
Your class has learned about monitoring. They understand the importance of checking on things and keeping records.
Your family has learned about monitoring. They understand the importance of checking on things and keeping track of what happens.
A Nigerian developer has learned all these concepts. They can now monitor their apps, log everything, and understand why problems happen.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 Monitoring = Watch systems for problems |
| 📌 Metrics = Numbers about system health |
| 📌 Prometheus = Collects metrics |
| 📌 Grafana = Visualizes metrics |
| 📌 Logging = Record events |
| 📌 ELK Stack = Logging tools |
| 📌 Observability = Understand why |
| 📌 APM = App performance monitoring |
| 📌 Alerting = Notify when problems occur |
| 📌 Incident Response = Fix problems |
| 📌 All work with DevOps for reliability |
| |
| YOU ARE NOW A MONITORING BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about monitoring, logging, and observability. These practices help us see what is happening in our systems, understand why, and respond quickly. They are essential for reliable software.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Monitoring | Watching systems to make sure they are working properly |
| Metric | A number that tells us about system health |
| Prometheus | A tool that collects and stores metrics |
| Grafana | A tool that creates dashboards from metrics |
| Logging | Recording events that happen in software |
| Log | A record of an event |
| ELK Stack | A set of logging tools (Elasticsearch, Logstash, Kibana) |
| Observability | The ability to understand why something is happening |
| Trace | A record of a request through the system |
| APM | Application Performance Monitoring |
| Alerting | Sending notifications when something goes wrong |
| Incident Response | The process of fixing problems |
| Latency | How long it takes to respond |
| Throughput | How many requests are processed |
| Dashboard | A screen that shows metrics and logs |
Here are the most important concepts from this module. These are the big ideas that will help you understand monitoring, logging, and observability.
Monitoring gives you real-time visibility. Monitoring watches your systems and tells you when something is wrong. It is like a dashboard for your software.
Metrics are numbers that matter. Metrics like CPU usage, response time, and error rate tell you about the health of your systems. They help you make decisions.
Prometheus and Grafana are a powerful pair. Prometheus collects metrics. Grafana visualizes them. Together, they give you a complete monitoring solution.
Logging records everything. Logs are like a diary for your software. They record every event and help you investigate problems.
The ELK Stack is a complete logging solution. Elasticsearch stores logs, Logstash collects them, and Kibana visualizes them. They work together like a library system for logs.
Observability helps you understand why. Monitoring tells you something is wrong. Observability tells you why. It uses metrics, logs, and traces to find the root cause.
Alerting and incident response save time. Alerts tell you when something is wrong. Incident response is the plan to fix it. Together, they help you recover quickly.
These practices are essential for DevOps. Monitoring, logging, and observability are core parts of DevOps. They help teams build and run reliable software.
Let us look at how to set up monitoring, logging, and observability in simple steps:
Decide which monitoring tool to use. Prometheus is a popular choice. It is open source and works with many systems.
Download and install Prometheus on your server. Configure it to collect metrics from your systems.
Install Grafana and connect it to Prometheus. Create dashboards to visualize your metrics.
Install the ELK Stack or another logging solution. Configure your applications to send logs to the logging system.
Configure alerts in Prometheus or Grafana. Set thresholds for important metrics (e.g., error rate > 1%, response time > 500ms).
Write a plan for how to respond when alerts fire. Include steps for diagnosing, containing, and fixing problems.
Test your alerts and dashboards regularly. Make sure they are working correctly. Improve them based on what you learn.
STEP-BY-STEP: SETTING UP MONITORING
Step 1: CHOOSE TOOL
+-------------------+
| Prometheus |
+-------------------+
|
V
Step 2: INSTALL PROMETHEUS
+-------------------+
| Configure to |
| collect metrics |
+-------------------+
|
V
Step 3: SET UP GRAFANA
+-------------------+
| Connect to |
| Prometheus |
| Create dashboards|
+-------------------+
|
V
Step 4: SET UP LOGGING
+-------------------+
| Install ELK Stack|
| Send logs |
+-------------------+
|
V
Step 5: SET UP ALERTING
+-------------------+
| Configure alerts |
| Set thresholds |
+-------------------+
|
V
Step 6: CREATE RESPONSE PLAN
+-------------------+
| Write plan for |
| fixing problems |
+-------------------+
|
V
Step 7: TEST & ITERATE
+-------------------+
| Test and improve |
+-------------------+
An e-commerce company uses Prometheus and Grafana to monitor their website. They have dashboards showing CPU, memory, request rate, and error rate. They have alerts set up for high error rates and slow response times.
A mobile app team uses the ELK Stack for logging. Logstash collects logs from their app. Elasticsearch stores them. Kibana provides a dashboard where the team can search and analyze logs.
A bank uses APM to monitor their mobile app. They track response times, error rates, and user experience. If the app is slow, they can see exactly where the problem is and fix it quickly.
Flutterwave uses Prometheus and Grafana to monitor their payment platform. They have dashboards that show transaction success rates, response times, and error rates. This helps them provide reliable service.
Paystack uses logging and observability to monitor their payment processing. They log every transaction and use tracing to understand the flow of requests. This helps them find and fix problems quickly.
A Nigerian tech startup uses monitoring, logging, and observability. They have alerts set up for their app. If something goes wrong, they are notified immediately and can fix it before users are affected.
You are playing a video game. You have a dashboard that shows your health, ammo, and energy. Monitoring is like that dashboard for your software — it shows you how your software is doing.
You keep a diary of what you did each day. Logging is like that diary for your software — it records everything that happens.
You are a detective solving a mystery. You collect clues (monitoring), interview witnesses (logging), and figure out what happened (observability). Observability is like being a detective for your software.
Your family car has a dashboard. It shows speed, fuel, and temperature. Monitoring is like the dashboard for your software.
Your school keeps records of attendance and grades. Logging is like those records for your software.
A doctor checks your vital signs (monitoring), reviews your medical history (logging), and runs tests to find the cause (observability). This is exactly what monitoring, logging, and observability do for software.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about monitoring, logging, and observability. Here are some tips to support their learning:
Mistake 1: Monitoring everything but not knowing what matters.
It is easy to collect too many metrics. Focus on metrics that matter to your users (like response time and error rate) and your business (like transaction success rate).
Mistake 2: Not setting up alerts.
Monitoring without alerting is not very useful. You need alerts to tell you when something is wrong. Otherwise, you might not notice a problem until users tell you.
Mistake 3: Too many alerts.
If you have too many alerts, people will ignore them. Set up alerts only for things that really matter. This is called "alert fatigue."
Mistake 4: Not checking logs regularly.
Logs are only useful if you look at them. Set up dashboards and alerts for your logs. Make it easy to search and analyze them.
Mistake 5: Not having an incident response plan.
If you get an alert but do not know what to do, you will waste time. Have a plan for how to respond to different types of problems.
Mistake 6: Not testing your alerts.
Alerts can break just like anything else. Test your alerts regularly to make sure they work.
Focus on user-impacting metrics.
Monitor things that affect your users. Response time, error rate, and availability are the most important metrics.
Set up actionable alerts.
Each alert should tell you what is wrong and what to do about it. Include the metric, the threshold, and a link to the dashboard.
Use dashboards for visibility.
Create dashboards that show your most important metrics. Make them available to your whole team. A picture is worth a thousand words.
Centralize your logs.
Send all logs to a central location like the ELK Stack. This makes it easy to search and analyze them. You can see the big picture.
Have an incident response plan.
Write down what to do when something goes wrong. Include steps for diagnosing, containing, and fixing problems. Practice it regularly.
Review and improve.
After an incident, review what happened. Figure out what went well and what could be improved. Use this to make your systems and processes better.
Test your alerts.
Make sure your alerts work by testing them regularly. Simulate problems and see if the alerts fire correctly.
MONITORING STACK
+--------------------------------------------------+
| PROMETHEUS (Collects metrics) |
| +-------------------------------------------+ |
| | CPU: 45% | |
| | Memory: 60% | |
| | Requests: 1,234/s | |
| | Errors: 0.5% | |
| +-------------------------------------------+ |
| | |
| V |
| GRAFANA (Visualizes metrics) |
| +-------------------------------------------+ |
| | 📊 CPU Usage | |
| | ██████████████████░░░░ 80% | |
| | 📈 Request Rate | |
| | ████████████████████░░ 1,234/s | |
| | 🔴 Error Rate | |
| | ████░░░░░░░░░░░░░░░░ 0.5% | |
| +-------------------------------------------+ |
| |
| TEAM SEES THE BIG PICTURE! |
+--------------------------------------------------+
ELK STACK
+--------------------------------------------------+
| LOGSTASH (Collector) |
| +-------------------------------------------+ |
| | Collects logs from servers, apps, and | |
| | containers | |
| +-------------------------------------------+ |
| | |
| V |
| ELASTICSEARCH (Storage) |
| +-------------------------------------------+ |
| | Stores and indexes logs | |
| | Fast search capabilities | |
| +-------------------------------------------+ |
| | |
| V |
| KIBANA (Visualization) |
| +-------------------------------------------+ |
| | 📊 Log Analysis | |
| | 🔍 Search logs | |
| | 📈 Visualize trends | |
| +-------------------------------------------+ |
+--------------------------------------------------+
ALERTING AND RESPONSE
+--------------------------------------------------+
| ALERT TRIGGERED |
| +-------------------------------------------+ |
| | 🚨 Error rate is above 1%! | |
| | Service: Payment System | |
| | Time: 10:05 AM | |
| +-------------------------------------------+ |
| | |
| V |
| INCIDENT RESPONSE |
| +-------------------------------------------+ |
| | 1. Detect: Alert received | |
| | 2. Diagnose: What is wrong? | |
| | 3. Contain: Stop it from spreading | |
| | 4. Fix: Fix the root cause | |
| | 5. Recover: Restore service | |
| | 6. Review: Learn and improve | |
| +-------------------------------------------+ |
| | |
| V |
| SERVICE RESTORED! |
| +-------------------------------------------+ |
| | ✅ System is healthy again! | |
| +-------------------------------------------+ |
+--------------------------------------------------+
| Aspect | Monitoring | Logging | Observability |
|---|---|---|---|
| What It Does | Watches systems for problems | Records events | Explains why problems happen |
| Data Type | Metrics (numbers) | Events (text) | Metrics + Logs + Traces |
| Question It Answers | "Is it working?" | "What happened?" | "Why did it happen?" |
| Tools | Prometheus, Grafana | ELK Stack | Prometheus, ELK, Jaeger |
| Analogy | Car dashboard | Diary | Medical diagnosis |
| Aspect | Prometheus | ELK Stack |
|---|---|---|
| Primary Use | Metrics | Logs |
| Data Type | Numbers | Text |
| Storage | Time series database | Search engine (Elasticsearch) |
| Query Language | PromQL | Lucene query syntax |
| Visualization | Grafana | Kibana |
| Collector | Pull-based | Logstash (push-based) |
| Level | Meaning | Action Required | Example |
|---|---|---|---|
| Critical | System is down or severely degraded | Immediate response required | Website is down |
| High | Significant problem affecting users | Respond within 15 minutes | High error rate |
| Medium | Problem that might affect users soon | Respond within 1 hour | CPU usage is high |
| Low | Informational, not urgent | Respond within 24 hours | Disk is almost full |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 7 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Monitoring is the practice of watching your systems to make sure they are working properly. It uses metrics (numbers) to track system health. Prometheus collects metrics, and Grafana visualizes them.
Logging is the practice of recording events that happen in your software. Logs are like a diary for your software. The ELK Stack (Elasticsearch, Logstash, Kibana) is a popular logging solution.
Observability is the ability to understand why something is happening. It combines metrics, logs, and traces to help you find the root cause of problems.
Alerting sends notifications when something goes wrong. Incident response is the plan for fixing the problem. Together, they help you recover quickly.
Monitoring, logging, and observability are core parts of DevOps. They help teams see what is happening, understand why, and respond quickly. Together, they make software reliable.
You have now completed Module 7! You are ready to move on to Module 8, where you will learn about DevSecOps and Security in DevOps. Keep up the great work!
Q1: What is monitoring?
A: Monitoring is the practice of watching your systems to make sure they are working properly. It checks things like CPU usage, memory, and response time.
Q2: What is the difference between monitoring and observability?
A: Monitoring tells you if something is wrong. Observability tells you why it is wrong. Monitoring answers "Is it working?" Observability answers "Why is it not working?"
Q3: What is Prometheus?
A: Prometheus is a popular tool for collecting and storing metrics. It pulls data from systems and stores it in a time series database.
Q4: What is Grafana?
A: Grafana is a tool that creates beautiful dashboards from metrics. It turns numbers into graphs and charts.
Q5: What is logging?
A: Logging is the practice of recording events that happen in your software. Logs are like a diary for your software.
Q6: What is the ELK Stack?
A: The ELK Stack is a set of logging tools: Elasticsearch (storage), Logstash (collection), and Kibana (visualization).
Q7: What is an alert?
A: An alert is a notification sent when something goes wrong. It tells you that a metric has crossed a threshold.
Q8: What is incident response?
A: Incident response is the process of fixing problems when they occur. It includes steps for diagnosing, containing, and fixing issues.
Q9: What are the three pillars of observability?
A: The three pillars of observability are metrics (numbers), logs (events), and traces (request paths).
Q10: Is monitoring used in Nigeria?
A: Yes, many Nigerian companies use monitoring, logging, and observability to ensure their systems are reliable.
What is monitoring?
Answer: Monitoring is the practice of watching your systems to make sure they are working properly.
Why do we need monitoring?
Answer: We need monitoring to find problems early and fix them quickly before users are affected.
What are metrics?
Answer: Metrics are numbers that tell us about the health of our systems.
What is Prometheus?
Answer: Prometheus is a tool that collects and stores metrics.
What is Grafana?
Answer: Grafana is a tool that creates dashboards from metrics.
What is logging?
Answer: Logging is the practice of recording events that happen in your software.
What does ELK stand for?
Answer: Elasticsearch, Logstash, and Kibana.
What is observability?
Answer: Observability is the ability to understand why something is happening in your system.
What are the three pillars of observability?
Answer: Metrics, logs, and traces.
What is APM?
Answer: APM stands for Application Performance Monitoring. It focuses on the performance of applications.
What is an alert?
Answer: An alert is a notification sent when something goes wrong.
What is incident response?
Answer: Incident response is the process of fixing problems when they occur.
Name two best practices for alerting.
Answer: Alert on symptoms, not causes. Keep alerts actionable. Do not create alert fatigue. (Any two are acceptable.)
Is monitoring part of DevOps?
Answer: Yes, monitoring, logging, and observability are core parts of DevOps.
Is monitoring used in Nigeria?
Answer: Yes, many Nigerian companies use monitoring for their systems.
Fill in the blanks with the correct words from the list:
Word list: monitoring, metrics, Prometheus, Grafana, logging, ELK, observability, traces, APM, alerting, incident response, dashboard
__________ is the practice of watching your systems to make sure they are working properly.
Answer: monitoring
__________ are numbers that tell us about the health of our systems.
Answer: metrics
__________ is a tool that collects and stores metrics.
Answer: Prometheus
__________ is a tool that creates dashboards from metrics.
Answer: Grafana
__________ is the practice of recording events in your software.
Answer: logging
The __________ Stack is a set of logging tools.
Answer: ELK
__________ is the ability to understand why something is happening.
Answer: observability
__________ are records of requests through the system.
Answer: traces
__________ monitors application performance.
Answer: APM
__________ is sending notifications when something goes wrong.
Answer: alerting
__________ is the process of fixing problems when they occur.
Answer: incident response
A __________ shows metrics and logs in one place.
Answer: dashboard
Write True or False for each statement:
Monitoring helps you find problems early.
Answer: True
Metrics are text-based records of events.
Answer: False (Metrics are numbers. Logs are text-based records.)
Prometheus collects metrics.
Answer: True
Grafana collects metrics.
Answer: False (Grafana visualizes metrics. Prometheus collects them.)
Logging records events in your software.
Answer: True
The ELK Stack is used for monitoring.
Answer: False (The ELK Stack is used for logging.)
Observability explains why problems happen.
Answer: True
Traces are records of requests through the system.
Answer: True
APM is a type of monitoring for applications.
Answer: True
Alerting means fixing problems when they occur.
Answer: False (Alerting sends notifications. Incident response fixes problems.)
Incident response is the process of fixing problems.
Answer: True
Monitoring is not part of DevOps.
Answer: False (Monitoring is a core part of DevOps.)
A dashboard shows metrics and logs.
Answer: True
Observability is the same as monitoring.
Answer: False (Observability goes beyond monitoring to explain why.)
Monitoring is used in Nigeria.
Answer: True
Choose the correct answer for each question:
What is monitoring?
A) Recording events in software
B) Watching systems to make sure they are working
C) Understanding why problems happen
D) Fixing problems
Answer: B
What are metrics?
A) Text-based records of events
B) Numbers about system health
C) Records of requests through the system
D) Notifications about problems
Answer: B
What is Prometheus?
A) A tool that visualizes metrics
B) A tool that collects and stores metrics
C) A logging tool
D) A programming language
Answer: B
What is Grafana?
A) A tool that collects metrics
B) A tool that creates dashboards from metrics
C) A logging tool
D) A programming language
Answer: B
What is logging?
A) Watching systems for problems
B) Recording events in software
C) Understanding why problems happen
D) Fixing problems
Answer: B
What does ELK stand for?
A) Elasticsearch, Logstash, Kibana
B) Elastic, Logging, Kibana
C) Elasticsearch, Linux, Kibana
D) Elastic, Logstash, Kubernetes
Answer: A
What is observability?
A) Watching systems for problems
B) Recording events
C) Understanding why problems happen
D) Fixing problems
Answer: C
What are the three pillars of observability?
A) CPU, Memory, Disk
B) Metrics, Logs, Traces
C) Prometheus, Grafana, ELK
D) Development, Operations, Security
Answer: B
What is APM?
A) Application Performance Monitoring
B) Automatic Performance Management
C) Application Programming Model
D) Advanced Performance Metrics
Answer: A
What is alerting?
A) Fixing problems
B) Sending notifications when something goes wrong
C) Recording events
D) Understanding why problems happen
Answer: B
What is incident response?
A) Sending notifications
B) The process of fixing problems
C) Recording events
D) Understanding why problems happen
Answer: B
What is a trace?
A) A number about system health
B) A record of a request through the system
C) A notification about a problem
D) A record of an event
Answer: B
Is monitoring part of DevOps?
A) No
B) Yes, it is a core part
C) Sometimes
D) Only for large companies
Answer: B
What is a dashboard?
A) A tool that collects metrics
B) A screen that shows metrics and logs
C) A logging tool
D) A programming language
Answer: B
Is monitoring used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Monitoring | A. Records events in software |
| 2. Metrics | B. A tool that collects metrics |
| 3. Prometheus | C. Watching systems for problems |
| 4. Grafana | D. Understanding why problems happen |
| 5. Logging | E. Numbers about system health |
| 6. ELK Stack | F. Sending notifications about problems |
| 7. Observability | G. A tool that creates dashboards |
| 8. Traces | H. A set of logging tools |
| 9. Alerting | I. Records of requests through the system |
| 10. Incident Response | J. The process of fixing problems |
Answers:
What is monitoring and why is it important?
Answer: Monitoring is the practice of watching your systems to make sure they are working properly. It is important because it helps you find problems early and fix them quickly before users are affected. It is like a dashboard for your software.
Explain the difference between monitoring, logging, and observability.
Answer: Monitoring tells you if something is wrong (like checking vital signs). Logging records events that happen (like a diary). Observability tells you why something is happening (like a doctor's diagnosis). Monitoring asks "Is it working?" Logging asks "What happened?" Observability asks "Why did it happen?"
What is Prometheus and how does it work with Grafana?
Answer: Prometheus collects and stores metrics from systems. Grafana visualizes those metrics on dashboards. Prometheus is like a notebook for data. Grafana is like a corkboard that shows the data visually. Together, they provide a complete monitoring solution.
Describe the ELK Stack and its components.
Answer: The ELK Stack is a set of logging tools. Elasticsearch stores and indexes logs so they can be searched quickly. Logstash collects logs from various sources. Kibana visualizes logs on dashboards. Together, they provide a complete logging solution.
How do alerting and incident response work together?
Answer: Alerting sends notifications when something goes wrong. It is like a fire alarm. Incident response is the plan for fixing the problem when an alert is triggered. It is like the fire drill. Alerting tells you there is a problem. Incident response tells you what to do about it. Together, they help you recover quickly.
A company's website is slow. Users are complaining. The team does not know why the website is slow.
Question: How could monitoring, logging, and observability help the team?
Answer: Monitoring would show that response times are high. Logging would show errors and slow queries. Observability would help the team trace the request through the system and find the root cause (e.g., a slow database query). The team could then fix the problem.
A Nigerian e-commerce company's website crashed during a big sale. They did not know until customers started calling.
Question: How could alerting help this company?
Answer: Alerting could have notified the team immediately when the website went down. They could have started fixing the problem within minutes instead of waiting for customers to call. This would have reduced downtime and saved sales.
A Nigerian fintech company wants to monitor their payment app. They have many users and need to make sure the app is always available.
Question: What should they set up to monitor their app?
Answer: They should set up Prometheus to collect metrics (response time, error rate, transaction success rate). They should use Grafana to create dashboards. They should use the ELK Stack for logging. They should set up alerts for high error rates and slow response times. They should have an incident response plan for when alerts fire.
Instructions:
Instructions:
Why do you think monitoring is important for software?
Discuss with your classmates and share your ideas.
Have you ever used a dashboard or tracker? What did you use it for?
Share your experiences and thoughts.
What are some other situations where keeping a log or diary is helpful?
Think about school, home, and other activities.
Do you think observability is always necessary? Why or why not?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from monitoring?
Share examples of companies in Nigeria.
What do you think is the most important part of a monitoring system?
Explain why you think so.
Do you think monitoring is easy to set up? Why or why not?
Share your thoughts.
What is the most important thing you learned about monitoring today?
Share with the class.
Goal: Create a simple guide to teach beginners about monitoring, logging, and observability.
Instructions:
Goal: Learn about real-world monitoring practice.
Instructions:
Scenario:
You are a monitoring architect at a Nigerian company. The company has 20 developers working on a large web application. They want to set up monitoring, logging, and observability for their application.
The company has:
Challenge: Create a complete monitoring, logging, and observability plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 7: "Monitoring, Logging & Observability." You now understand how monitoring helps you see what is happening in your systems, how logging records events, and how observability helps you understand why problems happen.
In Module 8, you will learn:
Before you start Module 8, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 8! 🚀
© 2026 Certified DevOps Engineer Course • Module 7: Monitoring, Logging & Observability
Welcome to the very first module of our Certified DevOps Engineer course! This module is called "Introduction to DevOps: What, Why, and How." In this module, we will learn all about DevOps — what it is, why it is important, and how it helps people build better software faster.
DevOps is a very important topic in the world of technology. It helps teams work together, build software more quickly, and make sure that software works properly. Think of DevOps as a way to make the whole process of creating software smoother and more fun!
Hello and welcome! This is Module 1 of the Certified DevOps Engineer course. In this module, we are going to start our journey into the world of DevOps.
But first, let us think about something we all know — building things. When you build something, like a house or a treehouse, you need a plan, you need materials, and you need people to help you. Building software (like the apps on your phone or the websites you visit) is similar. People work together to create software, and they need to work in a way that is organized and efficient.
DevOps is a way of working together to build software. It brings together two groups of people: the "Developers" (who write the code) and the "Operations" people (who make sure the software runs properly on computers and servers). By working together, they can build better software, faster.
In this module, we will learn all about DevOps. We will use simple words, fun stories, and lots of examples. By the end of this module, you will understand what DevOps is and why it is so important in the technology world.
So, are you ready? Let us dive in and discover the amazing world of DevOps!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company that built software for schools. The company was called "EduTech Solutions."
EduTech Solutions had two teams of people. One team was called the "Developers." Their job was to write the code — the instructions that make the software work. They were very creative and loved building new features.
The other team was called the "Operations" team. Their job was to make sure the software ran properly on the computers and servers. They made sure the software was available for students and teachers to use.
Here was the problem: the two teams did not talk to each other very much. The Developers would write code and then "throw it over the wall" to the Operations team. The Operations team would then try to make it work, but they often had problems because they did not understand the code.
The Developers wanted to add new features quickly. The Operations team wanted to make sure everything was stable and did not break. They had different goals, and they did not work well together.
One day, the company lost a big customer because the software kept breaking. The customer was frustrated and went to a competitor. The company knew something had to change.
That is when the company discovered DevOps. DevOps is a way of working that brings Developers and Operations together. They start talking to each other, sharing ideas, and working as one team.
With DevOps, the Developers and Operations people started meeting regularly. They planned together, built together, and solved problems together. The software became more reliable, and they could add new features much faster.
The company grew and became very successful. And it all started because they learned to work together through DevOps.
This story shows us how important it is for different teams to work together. DevOps helps teams do exactly that. Let us learn more about this amazing way of working!
DevOps is a way of working where the people who build software (Developers) and the people who run the software (Operations) work together as one team.
The word "DevOps" comes from combining two words: Dev (short for Development) and Ops (short for Operations).
DevOps is important because it helps teams build software faster, with fewer problems. When Developers and Operations work together, they can catch mistakes early and fix them quickly. This means better software for everyone!
Imagine you are building a treehouse with your friends. Some of your friends are good at designing (the Developers). Others are good at building and making sure the treehouse is safe (the Operations team).
If the designers do not talk to the builders, they might design a treehouse that is impossible to build. Or the builders might build it differently than the designers wanted. But if they work together, they can build an amazing treehouse that everyone loves!
DevOps is exactly the same but for building software. It brings the "designers" (Developers) and the "builders" (Operations) together.
A company called "PayNaija" builds a payment app. The Developers write the code for the app. The Operations team makes sure the app runs on the servers. With DevOps, they work together so the app is always available and works perfectly.
Imagine your school is putting on a play. The scriptwriters (Developers) write the script. The stage crew (Operations) sets up the stage and lights. If they work together, the play is a success. If they do not talk, the play might be a disaster!
Your family is planning a vacation. Some people plan the activities (Developers). Others handle the travel and accommodation (Operations). If you all work together, you have a great vacation. If not, things can go wrong.
A Nigerian bank uses DevOps to build its mobile banking app. The Developers and Operations teams work together. The app is updated frequently with new features, and it rarely crashes. Customers are happy!
WHAT IS DEVOPS?
+-------------------+ +-------------------+
| DEVELOPMENT | | OPERATIONS |
| (Developers) | | (Ops Team) |
| | | |
| Write code | | Run software |
| Build features | | Keep it running |
| Create new stuff | | Fix problems |
+-------------------+ +-------------------+
| |
| DEVOPS BRINGS |
| THEM TOGETHER! |
| |
V V
+------------------------------------------+
| |
| DEVOPS TEAM |
| |
| Developers + Operations = Better, |
| faster software! |
| |
+------------------------------------------+
DevOps is a way of working where Developers and Operations people work together as one team. It helps teams build better software, faster.
Why we need DevOps: We need DevOps because the old way of building software had many problems. Developers and Operations did not work together, and this caused delays, mistakes, and unhappy customers.
Understanding why we need DevOps helps us appreciate how much better it is to work together. It shows us the problems that DevOps solves.
Think about a relay race. In a relay race, one runner passes a baton to the next runner. If they do not pass it smoothly, they drop the baton and lose the race.
In the old way of building software, Developers would "pass the baton" (the code) to Operations. But they did not pass it smoothly. The Operations team often could not understand the code, and things broke. DevOps is like teaching the runners to pass the baton perfectly every time.
| Problem | What It Meant |
|---|---|
| Slow Releases | It took months or even years to release new software. |
| Many Mistakes | Software often had bugs because teams did not test together. |
| Finger-Pointing | Developers blamed Operations when things broke, and vice versa. |
| Hard to Fix | When something broke, it took a long time to fix because no one knew the whole picture. |
| Unhappy Customers | Because software was slow and buggy, customers were not happy. |
A Nigerian e-commerce company used to release new features only once a year. Customers were frustrated because the app did not have the latest features. After adopting DevOps, they release new features every week. Customers are much happier.
Your class is working on a group project. If everyone works alone and does not share their work, the project will be a mess. But if everyone works together and shares ideas, the project is great. DevOps is like working together on a group project.
Your family is planning a big dinner. If everyone cooks without talking to each other, you might end up with three different types of rice and no meat. But if you plan together, you make a wonderful meal. DevOps is like planning together.
A Nigerian bank used to take months to update its mobile app. Customers complained about outdated features. After adopting DevOps, the bank can update the app in days. Customers are happier, and the bank keeps more customers.
THE PROBLEM BEFORE DEVOPS
DEVELOPMENT OPERATIONS
+-------------------+ +-------------------+
| Write code | | Run software |
| Build features | | Fix problems |
| | | |
| "We are done!" | ======> | "This does not |
| | throw | work!" |
| | over | |
| | wall | "It is the |
| | | developer's |
| | | fault!" |
+-------------------+ +-------------------+
RESULT: SLOW, BUGGY, UNHAPPY CUSTOMERS
THE SOLUTION: DEVOPS!
DEVELOPMENT AND OPERATIONS WORK TOGETHER
+------------------------------------------+
| |
| "Let us work together!" |
| "We will build it together!" |
| "We will fix problems together!" |
| |
| RESULT: FAST, RELIABLE, HAPPY CUSTOMERS |
| |
+------------------------------------------+
We need DevOps because the old way of building software had many problems. Developers and Operations did not work together, causing slow releases, many mistakes, and unhappy customers. DevOps solves all these problems.
The history of DevOps is the story of how DevOps came to be. It started because people realized that the old way of building software was not working well.
Understanding the history of DevOps helps us understand why it is so important today. It shows us that DevOps was created to solve real problems.
Imagine you are playing a video game. The game has two teams. One team designs the levels, and the other team makes sure the game runs smoothly. But the two teams never talk to each other. The level designers make levels that are too hard for the game engine to run. The game crashes, and players are unhappy.
The game developers realize they need to work together. They start meeting and talking. They plan together. The game becomes amazing. That is the story of how DevOps started!
| Year | Event | What Happened |
|---|---|---|
| 2000s | Agile Movement | People realized that building software in a flexible, iterative way was better than doing everything at once. |
| 2009 | First DevOps Conference | A conference called "Velocity 2009" talked about how Development and Operations should work together. |
| 2010-2013 | DevOps Grows | More companies started using DevOps. Tools like Jenkins, Ansible, and Docker were created to help. |
| 2014-2016 | DevOps Becomes Mainstream | DevOps became a standard way of working for many tech companies. |
| 2017-Present | DevOps Everywhere | DevOps is now used by companies all over the world, including many in Nigeria. |
A company called "Flutterwave" (a Nigerian fintech company) started using DevOps to build its payment platform. By working together, they built a platform that processes millions of transactions every day.
Your school used to plan events with teachers and students working separately. Now, they have meetings where everyone shares ideas. The events are much better because everyone works together.
Your family used to plan vacations with everyone making their own plans. Now, you have a family meeting where everyone shares ideas. The vacations are much more fun because everyone works together.
A Nigerian company called "Andela" uses DevOps to build software for clients all over the world. By working together, they deliver high- quality software quickly.
THE HISTORY OF DEVOPS TIMELINE
2000s
+-------------------+
| Agile Movement |
| People want to |
| work flexibly |
+-------------------+
|
V
2009
+-------------------+
| First DevOps |
| Conference |
| "Velocity 2009" |
+-------------------+
|
V
2010-2013
+-------------------+
| DevOps Grows |
| New tools like |
| Jenkins, Docker |
+-------------------+
|
V
2014-2016
+-------------------+
| DevOps Becomes |
| Mainstream |
| Many companies |
| adopt it |
+-------------------+
|
V
2017-Present
+-------------------+
| DevOps Everywhere|
| Used worldwide |
| Including Nigeria|
+-------------------+
DevOps started because people realized that working together was better than working separately. It has grown from an idea in 2009 to a standard way of working today.
The DevOps Lifecycle is the series of steps that a team follows to build, test, release, and monitor software. It is like a roadmap for building software.
The DevOps Lifecycle shows us all the stages of building software. It helps us understand the complete picture and see how DevOps helps at every stage.
Imagine you are baking a cake. You have a recipe that tells you every step: gather ingredients, mix them, bake the cake, and serve it. The DevOps Lifecycle is like a recipe for building software. It tells you every step from start to finish.
| Stage | What Happens | Simple Example |
|---|---|---|
| Plan | Decide what to build and how to build it | Planning the cake recipe and ingredients |
| Code | Write the software code | Mixing the cake ingredients |
| Build | Turn the code into a working program | Putting the cake in the oven |
| Test | Check that the software works correctly | Tasting the cake to make sure it is good |
| Release | Prepare the software to be used by customers | Decorating the cake and putting it on a plate |
| Deploy | Make the software available to users | Serving the cake to your family |
| Operate | Keep the software running properly | Making sure the cake is stored properly |
| Monitor | Watch the software to find problems | Checking if the cake is still fresh |
A Nigerian company building a mobile app follows the DevOps Lifecycle. They plan the features, write the code, build the app, test it, release it, deploy it to app stores, operate it, and monitor it for problems.
Your class is making a school newspaper. You plan the articles, write them, put them together, check for errors, print them, distribute them, and check if students like them. That is the lifecycle of a newspaper!
Your family is planning a party. You plan the party, prepare the food, set up the decorations, check everything is ready, host the party, and clean up afterwards. That is a lifecycle!
A Nigerian e-commerce company follows the DevOps Lifecycle to build its website. They plan new features, code them, build them, test them, release them, deploy them, operate the website, and monitor for issues.
THE DEVOPS LIFECYCLE
+--------------------------------------------------+
| |
| PLAN |
| (Decide what to build) |
| | |
| V |
| CODE |
| (Write the software) |
| | |
| V |
| BUILD |
| (Turn code into a program) |
| | |
| V |
| TEST |
| (Check it works) |
| | |
| V |
| RELEASE |
| (Prepare for users) |
| | |
| V |
| DEPLOY |
| (Make it available to users) |
| | |
| V |
| OPERATE |
| (Keep it running) |
| | |
| V |
| MONITOR |
| (Watch for problems) |
| | |
| V |
| (Go back to PLAN and repeat!) |
| |
+--------------------------------------------------+
The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
Core DevOps Principles are the main ideas that guide how DevOps works. They are like the rules of the game.
Principles are important because they guide our actions. When we know the principles, we know how to do things the right way.
Imagine you are playing football. There are rules like "no hands" and "score a goal to win." These rules guide how you play. DevOps principles are the rules that guide how teams build software together.
There are three main principles in DevOps. They are called "The Three Ways." Let us learn about each one.
Definition: The First Way is about making the flow of work from Development to Operations fast and smooth.
Simple Explanation: Imagine a river. The water flows smoothly from the mountains to the ocean. The First Way is about making the work flow smoothly from the developer to the user.
Definition: The Second Way is about getting feedback quickly. When something goes wrong, we need to know immediately so we can fix it.
Simple Explanation: Imagine you are cooking. If you taste the food while cooking, you can add more salt if it needs it. If you wait until the end, it might be too late. The Second Way is about tasting the food early and often.
Definition: The Third Way is about always learning and improving. We should always look for ways to do things better.
Simple Explanation: Imagine you are playing a video game. Every time you lose, you learn something new. You try again and get better. The Third Way is about always learning and improving.
A Nigerian company follows the Three Ways. They release software quickly (Flow), they get feedback from users quickly (Feedback), and they always look for ways to improve (Continuous Learning).
Your school project team follows the Three Ways. You work smoothly together (Flow), you give each other feedback (Feedback), and you learn from mistakes (Continuous Learning).
Your family plans a party. You work together smoothly (Flow), you ask guests for feedback (Feedback), and you learn what to do better next time (Continuous Learning).
A Nigerian company building a delivery app follows the Three Ways. They release updates quickly (Flow), they get feedback from customers (Feedback), and they always improve (Continuous Learning).
THE THREE WAYS OF DEVOPS
+--------------------------------------------------+
| |
| THE FIRST WAY: FLOW |
| +------------------------------------+ |
| | Make work flow smoothly from | |
| | Development to Operations | |
| | "Keep the river flowing" | |
| +------------------------------------+ |
| | |
| V |
| THE SECOND WAY: FEEDBACK |
| +------------------------------------+ |
| | Get feedback quickly | |
| | "Taste the food while cooking" | |
| +------------------------------------+ |
| | |
| V |
| THE THIRD WAY: CONTINUOUS LEARNING |
| +------------------------------------+ |
| | Always learn and improve | |
| | "Get better every day" | |
| +------------------------------------+ |
| |
| TOGETHER, THEY MAKE DEVOPS WORK! |
| |
+--------------------------------------------------+
The core DevOps principles are called the Three Ways. The First Way is about smooth flow. The Second Way is about quick feedback. The Third Way is about continuous learning.
DevOps culture is the way people think and behave when they work in a DevOps team. It is about working together, sharing ideas, and helping each other.
Culture is important because it affects how people work. A good culture makes people happy and productive. A bad culture makes people unhappy and unproductive.
Imagine you are on a sports team. A good team cheers for each other, helps each other, and celebrates together. A bad team blames each other and does not work together. DevOps culture is like being on a good sports team.
| Element | What It Means |
|---|---|
| Collaboration | Working together, sharing ideas, and helping each other |
| Communication | Talking to each other openly and honestly |
| Trust | Believing that others will do their best work |
| Blame-Free | When something goes wrong, we fix it instead of blaming someone |
| Continuous Improvement | Always looking for ways to get better |
| Shared Goals | Everyone works towards the same goals |
A Nigerian company has a DevOps culture. The team meets daily, shares what they are working on, and helps each other. When something breaks, they fix it together instead of blaming anyone.
Your classroom has a good culture. Students help each other with homework, share supplies, and celebrate each other's successes.
Your family has a good culture. Everyone helps with chores, listens to each other, and supports each other.
A Nigerian tech startup has a DevOps culture. The Developers and Operations people sit together, talk openly, and work as one team. They are very successful because of their culture.
DEVOPS CULTURE
+--------------------------------------------------+
| |
| 🗣️ COMMUNICATION |
| Talk openly and honestly |
| |
| 🤝 COLLABORATION |
| Work together, share ideas |
| |
| ❤️ TRUST |
| Believe in each other |
| |
| ✅ BLAME-FREE |
| Fix problems, not blame people |
| |
| 📈 CONTINUOUS IMPROVEMENT |
| Always get better |
| |
| 🎯 SHARED GOALS |
| Everyone works towards the same goal |
| |
| TOGETHER = DEVOPS SUCCESS! 🚀 |
| |
+--------------------------------------------------+
DevOps culture is about working together, sharing ideas, and helping each other. Key elements include collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Agile is a way of building software where teams work in short cycles (called "sprints") and deliver small pieces of working software frequently. It is about being flexible and responding to change.
DevOps takes Agile and extends it. It brings in the Operations team so that the whole process of building and running software is smooth.
Understanding Agile helps us understand where DevOps came from. DevOps is like the "next step" after Agile.
Imagine you are building a house. The old way was to plan everything perfectly and build the whole house at once. Agile is like building the house room by room. You build the bedroom, then the kitchen, then the living room. You can change things as you go.
DevOps is like having the builders and the maintenance team work together. While the builders are building the house, the maintenance team is making sure everything is working properly. They work together from the start.
| Aspect | Agile | DevOps |
|---|---|---|
| Focus | Building software quickly and flexibly | Building and running software together |
| Teams | Development team | Development + Operations teams |
| Goal | Deliver working software frequently | Deliver working software frequently AND keep it running |
| Timeframe | Short sprints (2-4 weeks) | Continuous delivery (always ready to release) |
A Nigerian company uses Agile to build its app. They release new features every two weeks. They also use DevOps to make sure the app runs smoothly for all users.
Your class uses Agile to plan a school event. You plan a little bit at a time and adjust as you go. You also use DevOps by having the teachers and students work together.
Your family uses Agile to plan a vacation. You plan a little bit at a time and adjust. You also use DevOps by having everyone work together on the plan.
A Nigerian fintech company uses Agile to build new features quickly. They also use DevOps to make sure the features work properly for customers. Together, Agile and DevOps help them grow fast.
AGILE + DEVOPS = SUCCESS!
AGILE:
+--------------------------------------------------+
| Build software in short cycles (sprints) |
| Deliver small pieces frequently |
| Respond to change quickly |
| Focus on Development |
+--------------------------------------------------+
|
V
DEVOPS:
+--------------------------------------------------+
| Takes Agile and adds Operations |
| Development + Operations work together |
| Build AND run software |
| Continuous delivery and monitoring |
+--------------------------------------------------+
|
V
RESULT:
+--------------------------------------------------+
| Faster, better, more reliable software! |
| Happy developers, happy operations, happy users! |
+--------------------------------------------------+
Agile is a way of building software in short cycles. DevOps extends Agile by bringing in the Operations team so that building and running software are done together.
The benefits of DevOps are all the good things that happen when a team uses DevOps. These include faster releases, fewer problems, and happier customers.
Understanding the benefits helps us see why DevOps is so valuable. It helps us understand why so many companies are adopting DevOps.
Imagine you have a car. If you take good care of it, it runs smoothly, gets you where you need to go, and lasts a long time. DevOps is like taking good care of your software. The benefits are: it runs smoothly, it works well, and it lasts a long time.
| Benefit | What It Means |
|---|---|
| Faster Releases | Software is released more quickly, so users get new features sooner |
| Fewer Problems | Bugs and issues are caught and fixed early, so software is more reliable |
| Better Collaboration | Teams work together, share ideas, and help each other |
| Happy Customers | Because software works well and has new features, customers are happy |
| Less Stress | Teams work together to solve problems, so there is less stress |
| Continuous Improvement | Teams always look for ways to get better |
A Nigerian company adopted DevOps. Before DevOps, they released updates once a year. After DevOps, they release updates every week. Their customers are much happier.
Your school uses DevOps for its website. They release updates quickly, the website rarely breaks, and students and parents are happy.
Your family uses DevOps principles to plan events. Everyone works together, problems are fixed quickly, and events are successful.
A Nigerian e-commerce company uses DevOps. They release new features quickly, their website is very reliable, and their customers love them. The company has grown a lot because of DevOps.
THE BENEFITS OF DEVOPS
+--------------------------------------------------+
| |
| 🚀 FASTER RELEASES |
| New features reach users quickly |
| |
| 🐛 FEWER PROBLEMS |
| Bugs are caught and fixed early |
| |
| 🤝 BETTER COLLABORATION |
| Teams work together happily |
| |
| 😊 HAPPY CUSTOMERS |
| Users love the software |
| |
| 🧘 LESS STRESS |
| Teams are calm and effective |
| |
| 📈 CONTINUOUS IMPROVEMENT |
| Always getting better |
| |
| ALL BECAUSE OF DEVOPS! 🎉 |
| |
+--------------------------------------------------+
DevOps has many benefits. It leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
Who uses DevOps: DevOps is used by many different types of organizations. From small startups to big companies, from tech giants to banks, and even schools and governments.
Knowing who uses DevOps shows us that DevOps is not just for one type of organization. It can be used by anyone who builds software.
Imagine a toolbox. DevOps is like a toolbox that anyone can use. Whether you are building a small birdhouse or a big skyscraper, the toolbox has the tools you need. DevOps is like that — it works for all types of software projects.
A Nigerian bank uses DevOps to build its mobile banking app. The app is updated frequently and works reliably. Customers can transfer money, pay bills, and check balances easily.
Your school uses a learning platform to share lessons and assignments. The platform is built using DevOps principles. It is always available and has new features regularly.
Your family uses a family calendar app to coordinate activities. The app is built using DevOps. It is reliable and gets new features often.
Many Nigerian companies use DevOps. Flutterwave, Paystack, Andela, Interswitch, and many others use DevOps to build their products.
WHO USES DEVOPS?
+--------------------------------------------------+
| |
| 🏢 TECH COMPANIES |
| Google, Amazon, Microsoft |
| |
| 🏦 BANKS |
| Mobile banking, online banking |
| |
| 🛍️ E-COMMERCE |
| Jumia, Konga, Shopify |
| |
| 🏛️ GOVERNMENT |
| Citizen services, digital ID |
| |
| 🏫 SCHOOLS |
| Learning platforms, student systems |
| |
| 🏥 HOSPITALS |
| Patient management, health records |
| |
| 🚀 STARTUPS |
| Building new products quickly |
| |
| ANYONE WHO BUILDS SOFTWARE! |
| |
+--------------------------------------------------+
DevOps is used by many different organizations. Tech companies, banks, e-commerce, government, schools, hospitals, and startups all use DevOps.
In this lesson, we will review everything we have learned about DevOps. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A Nigerian company has learned all these DevOps concepts. They work together, release software quickly, and keep their customers happy.
Your class has learned about DevOps. You understand how working together helps you build better projects.
Your family has learned about DevOps. You understand how planning together, giving feedback, and learning from mistakes helps your family work better.
A Nigerian entrepreneur has learned about DevOps. They are starting a new tech company and plan to use DevOps from the beginning.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 DevOps = Development + Operations |
| 📌 We need DevOps to build better software |
| 📌 DevOps started around 2009 |
| 📌 The DevOps Lifecycle has 8 stages |
| 📌 The Three Ways: Flow, Feedback, Learning |
| 📌 DevOps culture = working together |
| 📌 Agile + DevOps = Building + Running |
| 📌 Benefits: faster, fewer problems, happier |
| 📌 Everyone uses DevOps! |
| |
| YOU ARE NOW A DEVOPS BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about DevOps. It is a way of working where Developers and Operations work together. It helps teams build better software, faster.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| DevOps | A way of working where Developers and Operations work together to build software. |
| Development | The team that writes the code and builds new features. |
| Operations | The team that makes sure the software runs properly on servers. |
| Agile | A way of building software in short cycles, delivering small pieces frequently. |
| DevOps Lifecycle | The series of steps to build, test, release, and monitor software. |
| Flow | The First Way of DevOps — making work flow smoothly. |
| Feedback | The Second Way of DevOps — getting feedback quickly. |
| Continuous Learning | The Third Way of DevOps — always learning and improving. |
| Collaboration | Working together and sharing ideas. |
| Communication | Talking to each other openly and honestly. |
| Culture | The way people think and behave in a group. |
| Continuous Improvement | Always looking for ways to get better. |
Here are the most important concepts from this module. These are the big ideas that will help you understand DevOps.
DevOps brings people together. DevOps is not just about tools. It is about people working together. The most important part of DevOps is the culture of collaboration.
The DevOps Lifecycle is a roadmap. It has eight stages: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. Each stage has important tasks.
The Three Ways are the rules of DevOps. The First Way is about Flow. The Second Way is about Feedback. The Third Way is about Continuous Learning.
DevOps culture is key. A good culture includes collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
DevOps helps everyone. It helps Developers, Operations, the company, and the customers. It leads to faster releases, fewer problems, and happier people.
Let us look at how DevOps works in simple steps:
The team decides what to build. They talk about the features, the timeline, and the goals. They plan the work.
The Developers write the code. They build the features that were planned. They write clean, organized code.
The code is turned into a working program. This is called "building." The team makes sure the program runs.
The team tests the program to make sure it works. They look for bugs and fix them. They make sure the software is high quality.
The software is prepared to be used by customers. This includes making sure it is ready and all the paperwork is done.
The software is made available to users. It is put on the servers where customers can access it.
The team keeps the software running. They make sure it is available and working properly.
The team watches the software to find problems. They look for errors, slow performance, and other issues. Then they go back to Step 1 and do it all again!
STEP-BY-STEP: THE DEVOPS LIFECYCLE
Step 1: PLAN
+-------------------+
| Decide what to |
| build |
+-------------------+
|
V
Step 2: CODE
+-------------------+
| Write the code |
+-------------------+
|
V
Step 3: BUILD
+-------------------+
| Turn code into |
| a program |
+-------------------+
|
V
Step 4: TEST
+-------------------+
| Check it works |
+-------------------+
|
V
Step 5: RELEASE
+-------------------+
| Prepare for |
| users |
+-------------------+
|
V
Step 6: DEPLOY
+-------------------+
| Make available |
| to users |
+-------------------+
|
V
Step 7: OPERATE
+-------------------+
| Keep it running |
+-------------------+
|
V
Step 8: MONITOR
+-------------------+
| Watch for |
| problems |
+-------------------+
|
V
(Repeat from Step 1!)
A large technology company uses DevOps to build its search engine. The Developers and Operations teams work together. They release updates to the search engine every day. The search engine is always improving, and users are happy.
A bank uses DevOps to build its mobile app. The team releases new features every two weeks. The app is reliable and secure. Customers can do their banking from their phones without any problems.
A hospital uses DevOps to build a patient management system. The system helps doctors and nurses manage patient records. It is always available and works perfectly. Patients get better care.
Flutterwave is a Nigerian fintech company that uses DevOps to build its payment platform. The platform processes millions of transactions every day. The team uses DevOps to release new features quickly and keep the platform running smoothly.
Paystack is a Nigerian payment company (now part of Stripe). They use DevOps to build their payment infrastructure. They release updates frequently and their platform is very reliable.
Andela is a Nigerian company that builds software for clients all over the world. They use DevOps to collaborate with clients and deliver high-quality software quickly.
Your school is putting on a play. The actors (Developers) practice their lines. The stage crew (Operations) sets up the stage and lights. If they work together, the play is a success. If they do not talk, the play might be a disaster. DevOps is like the actors and stage crew working together!
You and your friends are working on a group project for school. Some of you research, some of you write, and some of you design. If you all work together and share ideas, the project is great. DevOps is like working together on a group project.
You are planning a birthday party. Some friends plan the games, some plan the food, and some plan the decorations. If you all work together, the party is amazing. DevOps is like planning a party together!
Your family is cooking dinner. The person chopping vegetables (Development) and the person cooking on the stove (Operations) work together. Dinner is ready on time and everyone enjoys it.
You and your friends are building a treehouse. The designer (Development) and the builder (Operations) work together. The treehouse is strong and fun.
Your family is planning a trip. The person planning activities (Development) and the person planning travel (Operations) work together. The trip is wonderful.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about DevOps and how it helps teams build software together. Here are some tips to support their learning:
Mistake 1: Thinking DevOps is only about tools.
DevOps is much more than just tools. It is about culture, process, and people working together. Tools are helpful, but they are not the most important part.
Mistake 2: Thinking DevOps is only for developers.
DevOps involves both Developers and Operations people. It is a team effort. Everyone works together.
Mistake 3: Thinking DevOps is easy.
DevOps takes effort and practice. It requires changing how people work and think. But it is worth it because of all the benefits.
Mistake 4: Blaming people when things go wrong.
In DevOps culture, we fix problems instead of blaming people. Blaming creates a bad culture. Fixing problems creates a good culture.
Mistake 5: Forgetting about continuous learning.
The Third Way is about always learning and improving. If you stop learning, you stop improving.
Mistake 6: Thinking DevOps is a one-time thing.
DevOps is a continuous process. You never "finish" DevOps. You keep improving and working together.
Start with culture, not tools.
Before you buy any tools, focus on building a good culture. Get people to work together and trust each other. Tools come later.
Start small.
You do not have to do everything at once. Start with one team or one project. Learn from that experience and then expand.
Automate everything.
In DevOps, we automate as much as possible. This includes building, testing, and deploying. Automation saves time and reduces mistakes.
Get feedback early and often.
Do not wait until the end to get feedback. Get feedback at every stage. This helps you catch problems early.
Learn from failures.
When something goes wrong, do not blame anyone. Instead, ask: "What did we learn?" and "How can we prevent this in the future?"
Keep improving.
Always look for ways to get better. There is always something you can improve.
THE DEVOPS LIFECYCLE
+--------------------------------------------------+
| |
| PLAN |
| (Decide what to build) |
| | |
| V |
| CODE |
| (Write the software) |
| | |
| V |
| BUILD |
| (Turn code into a program) |
| | |
| V |
| TEST |
| (Check it works) |
| | |
| V |
| RELEASE |
| (Prepare for users) |
| | |
| V |
| DEPLOY |
| (Make it available to users) |
| | |
| V |
| OPERATE |
| (Keep it running) |
| | |
| V |
| MONITOR |
| (Watch for problems) |
| | |
| V |
| (Go back to PLAN and repeat!) |
| |
+--------------------------------------------------+
THE THREE WAYS OF DEVOPS
+--------------------------------------------------+
| |
| THE FIRST WAY: FLOW |
| +------------------------------------+ |
| | Make work flow smoothly from | |
| | Development to Operations | |
| | "Keep the river flowing" | |
| +------------------------------------+ |
| | |
| V |
| THE SECOND WAY: FEEDBACK |
| +------------------------------------+ |
| | Get feedback quickly | |
| | "Taste the food while cooking" | |
| +------------------------------------+ |
| | |
| V |
| THE THIRD WAY: CONTINUOUS LEARNING |
| +------------------------------------+ |
| | Always learn and improve | |
| | "Get better every day" | |
| +------------------------------------+ |
| |
+--------------------------------------------------+
AGILE + DEVOPS
AGILE:
+--------------------------------------------------+
| Build software in short cycles (sprints) |
| Deliver small pieces frequently |
| Respond to change quickly |
| Focus on Development |
+--------------------------------------------------+
|
V
DEVOPS:
+--------------------------------------------------+
| Takes Agile and adds Operations |
| Development + Operations work together |
| Build AND run software |
| Continuous delivery and monitoring |
+--------------------------------------------------+
|
V
RESULT:
+--------------------------------------------------+
| Faster, better, more reliable software! |
| Happy developers, happy operations, happy users! |
+--------------------------------------------------+
| Aspect | Before DevOps | After DevOps |
|---|---|---|
| Collaboration | Teams worked separately | Teams work together |
| Releases | Slow (months or years) | Fast (days or weeks) |
| Problems | Many bugs and issues | Fewer problems |
| Culture | Blame culture | Blame-free culture |
| Learning | Learning was slow | Continuous learning |
| Customers | Unhappy customers | Happy customers |
| Aspect | Agile | DevOps |
|---|---|---|
| Focus | Building software | Building AND running software |
| Teams | Developers | Developers + Operations |
| Goal | Deliver working software | Deliver AND keep it running |
| Timeframe | Sprints (2-4 weeks) | Continuous delivery |
| Scope | Development only | Development + Operations |
| Way | What It Means | Simple Analogy |
|---|---|---|
| First Way (Flow) | Make work flow smoothly | A river flowing to the ocean |
| Second Way (Feedback) | Get feedback quickly | Tasting food while cooking |
| Third Way (Learning) | Always learn and improve | Getting better at a game |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 1 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
DevOps is a way of working where the people who build software (Developers) and the people who run the software (Operations) work together as one team. It helps teams build better software, faster.
We need DevOps because the old way of working separately caused problems like slow releases, many mistakes, finger-pointing, and unhappy customers. DevOps solves all these problems.
DevOps started around 2009 and has grown to be used by companies all over the world. It began with the Agile movement and evolved into a full way of working.
The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The eight stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
The Three Ways are the core principles of DevOps. The First Way is about Flow. The Second Way is about Feedback. The Third Way is about Continuous Learning.
DevOps culture is about working together, sharing ideas, and helping each other. Key elements include collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Agile is a way of building software in short cycles. DevOps extends Agile by bringing in the Operations team so that building and running software are done together.
DevOps leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
DevOps is used by tech companies, banks, e-commerce, government, schools, hospitals, and startups. Anyone who builds software can use DevOps.
You have now completed Module 1! You are ready to move on to Module 2, where you will learn about Version Control and Source Code Management. Keep up the great work!
Q1: What is DevOps?
A: DevOps is a way of working where Developers and Operations work together to build software. It helps teams build better software, faster.
Q2: Why is DevOps important?
A: DevOps is important because it solves the problems of the old way of working. It leads to faster releases, fewer problems, and happier customers.
Q3: Who uses DevOps?
A: DevOps is used by many different organizations. Tech companies, banks, e-commerce, government, schools, hospitals, and startups all use DevOps.
Q4: What are the Three Ways of DevOps?
A: The Three Ways are: Flow (making work flow smoothly), Feedback (getting feedback quickly), and Continuous Learning (always learning and improving).
Q5: What is the DevOps Lifecycle?
A: The DevOps Lifecycle is the series of steps to build, test, release, and monitor software. The stages are: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
Q6: What is the difference between Agile and DevOps?
A: Agile is about building software in short cycles. DevOps takes Agile and adds Operations so that building AND running software are done together.
Q7: What is DevOps culture?
A: DevOps culture is about working together, sharing ideas, and helping each other. It includes collaboration, communication, trust, being blame-free, continuous improvement, and shared goals.
Q8: What are the benefits of DevOps?
A: DevOps leads to faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement.
Q9: Do I need to be a developer to learn DevOps?
A: No! DevOps is for everyone. You can be a developer, an operations person, a manager, or anyone who works with software. DevOps is about people working together.
Q10: Is DevOps used in Nigeria?
A: Yes! Many Nigerian companies like Flutterwave, Paystack, and Andela use DevOps. It is helping Nigerian companies grow and compete globally.
What is DevOps?
Answer: DevOps is a way of working where Developers and Operations work together to build software.
Why do we need DevOps?
Answer: Because the old way of working separately caused problems like slow releases, many mistakes, and unhappy customers.
What does "DevOps" stand for?
Answer: DevOps combines "Development" and "Operations."
What are the eight stages of the DevOps Lifecycle?
Answer: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.
What are the Three Ways of DevOps?
Answer: Flow, Feedback, and Continuous Learning.
What is the First Way of DevOps?
Answer: The First Way is Flow — making work flow smoothly from Development to Operations.
What is the Second Way of DevOps?
Answer: The Second Way is Feedback — getting feedback quickly so problems can be fixed early.
What is the Third Way of DevOps?
Answer: The Third Way is Continuous Learning — always learning and improving.
What is DevOps culture?
Answer: DevOps culture is about working together, sharing ideas, and helping each other.
Name three elements of DevOps culture.
Answer: Collaboration, communication, trust, being blame-free, continuous improvement, and shared goals. (Any three are acceptable.)
What is Agile?
Answer: Agile is a way of building software in short cycles, delivering small pieces frequently.
How is DevOps different from Agile?
Answer: Agile focuses on Development. DevOps takes Agile and adds Operations so that building AND running software are done together.
Name two benefits of DevOps.
Answer: Faster releases, fewer problems, better collaboration, happy customers, less stress, and continuous improvement. (Any two are acceptable.)
Who uses DevOps?
Answer: Tech companies, banks, e-commerce, government, schools, hospitals, and startups.
Can DevOps be used in Nigeria?
Answer: Yes! Many Nigerian companies like Flutterwave, Paystack, and Andela use DevOps.
Fill in the blanks with the correct words from the list:
Word list: DevOps, Development, Operations, Agile, Flow, Feedback, Continuous Learning, Lifecycle, Culture, Three Ways
__________ is a way of working where Developers and Operations work together.
Answer: DevOps
The __________ team writes the code and builds new features.
Answer: Development
The __________ team makes sure the software runs properly.
Answer: Operations
__________ is a way of building software in short cycles.
Answer: Agile
The First Way of DevOps is __________.
Answer: Flow
The Second Way of DevOps is __________.
Answer: Feedback
The Third Way of DevOps is __________.
Answer: Continuous Learning
The DevOps __________ has eight stages.
Answer: Lifecycle
DevOps __________ is about working together and sharing ideas.
Answer: Culture
The core principles of DevOps are called the __________.
Answer: Three Ways
Write True or False for each statement:
DevOps is only about tools.
Answer: False
DevOps brings Developers and Operations together.
Answer: True
The DevOps Lifecycle has 5 stages.
Answer: False (It has 8 stages)
The First Way of DevOps is Feedback.
Answer: False (The First Way is Flow)
DevOps culture is about working together.
Answer: True
Agile and DevOps are the same thing.
Answer: False
DevOps leads to faster releases.
Answer: True
In DevOps culture, we blame people when things go wrong.
Answer: False (We fix problems instead of blaming people)
DevOps is used by many different organizations.
Answer: True
The Third Way of DevOps is about continuous learning.
Answer: True
DevOps is not used in Nigeria.
Answer: False
The DevOps Lifecycle never stops.
Answer: True
DevOps is only for developers.
Answer: False
DevOps helps make customers happy.
Answer: True
DevOps is a one-time thing.
Answer: False
Choose the correct answer for each question:
What is DevOps?
A) A programming language
B) A way of working where Developers and Operations work together
C) A type of computer
D) A video game
Answer: B
What does "DevOps" combine?
A) Development and Operations
B) Design and Operations
C) Development and Design
D) Data and Operations
Answer: A
How many stages are in the DevOps Lifecycle?
A) 5
B) 6
C) 8
D) 10
Answer: C
Which is NOT a stage in the DevOps Lifecycle?
A) Plan
B) Code
C) Sing
D) Monitor
Answer: C
What is the First Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: B
What is the Second Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: A
What is the Third Way of DevOps?
A) Feedback
B) Flow
C) Continuous Learning
D) Planning
Answer: C
Which is an element of DevOps culture?
A) Blaming people
B) Not communicating
C) Collaboration
D) Working alone
Answer: C
What is Agile?
A) A way of building software in short cycles
B) A way of running a marathon
C) A type of food
D) A video game
Answer: A
How is DevOps different from Agile?
A) DevOps is the same as Agile
B) DevOps adds Operations to Agile
C) DevOps is about design, not code
D) DevOps is older than Agile
Answer: B
Which is a benefit of DevOps?
A) Slower releases
B) More problems
C) Faster releases
D) Unhappy customers
Answer: C
Who uses DevOps?
A) Only tech companies
B) Only banks
C) Many different types of organizations
D) Only governments
Answer: C
Is DevOps used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
What is the most important part of DevOps?
A) Tools
B) People and culture
C) Computers
D) Money
Answer: B
What is the DevOps Lifecycle?
A) A series of steps to build, test, release, and monitor
software
B) A type of computer
C) A video game
D) A programming language
Answer: A
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. DevOps | A. The First Way — making work flow smoothly |
| 2. Development | B. The team that writes the code |
| 3. Operations | C. The team that runs the software |
| 4. Flow | D. A way of working where Developers and Operations work together |
| 5. Feedback | E. The Second Way — getting feedback quickly |
| 6. Continuous Learning | F. The Third Way — always learning and improving |
| 7. Agile | G. Building software in short cycles |
| 8. DevOps Lifecycle | H. The series of steps to build, test, release, and monitor software |
| 9. DevOps Culture | I. Working together, sharing ideas, and helping each other |
| 10. Three Ways | J. The core principles of DevOps |
Answers:
What is DevOps and why is it useful?
Answer: DevOps is a way of working where Developers and Operations work together to build software. It is useful because it leads to faster releases, fewer problems, and happier customers.
Explain the three stages of the DevOps Lifecycle.
Answer: The DevOps Lifecycle has eight stages: Plan (decide what to build), Code (write the software), Build (turn code into a program), Test (check it works), Release (prepare for users), Deploy (make it available), Operate (keep it running), and Monitor (watch for problems). Then it starts all over again.
What are the Three Ways of DevOps? Explain each one.
Answer: The Three Ways are:
What is DevOps culture and why is it important?
Answer: DevOps culture is about working together, sharing ideas, and helping each other. It is important because a good culture helps people work better together, which leads to better software and happier teams.
Give an example of how DevOps is used in Nigeria.
Answer: Flutterwave is a Nigerian fintech company that uses DevOps. They use DevOps to build their payment platform, which processes millions of transactions every day. They release new features quickly and keep the platform running smoothly.
A small tech startup in Lagos is building a new app. The Developers and Operations team do not talk to each other. The Developers build features quickly, but the Operations team cannot run them properly. The app keeps crashing, and customers are unhappy.
Question: How could DevOps help this startup?
Answer: DevOps could help by bringing the Developers and Operations team together. They would start talking, planning, and working together. The Developers would build features that the Operations team can run. The app would stop crashing, and customers would be happy.
A Nigerian bank wants to release new features for its mobile app more quickly. Currently, it takes 3 months to release any update. Customers are complaining about the lack of new features.
Question: How could DevOps help the bank release features faster?
Answer: DevOps could help the bank by making the flow of work smoother. The Developers and Operations teams would work together. They would build, test, and release features more quickly. Instead of taking 3 months, they could release updates in weeks or even days.
An e-commerce company in Nigeria has a website that goes down frequently during peak shopping times. Customers cannot place orders, and the company loses money.
Question: How could DevOps help prevent the website from crashing?
Answer: DevOps could help by improving collaboration between Developers and Operations. The Operations team would be involved from the start, helping the Developers build software that is more reliable. With DevOps, they would also monitor the website more closely and fix problems before they become big issues.
Instructions:
Instructions:
Why do you think teams often work separately instead of together?
Discuss with your classmates and share your ideas.
How would you feel if you were a Developer and the Operations team never talked to you?
Share your thoughts on why communication is important.
What are some other situations where people working together makes things better?
Think about different situations at home, at school, and in your community.
Do you think DevOps will become more or less important in the future? Why?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that might benefit from using DevOps?
Share examples of companies in Nigeria.
What do you think is the most important principle of DevOps?
Explain why you think so.
Do you think DevOps would help your school? How?
Think about different projects and activities at school.
What is the most important thing you learned about DevOps today?
Share with the class.
Goal: Create a simple guide to teach beginners about DevOps.
Instructions:
Goal: Observe how DevOps principles apply in your community.
Instructions:
Scenario:
You are a DevOps consultant hired by a Nigerian company that sells products online. The company has a website that is slow, frequently crashes, and takes 6 months to release any new features. Customers are frustrated and going to competitors.
The company has:
Challenge: Create a complete DevOps plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 1: "Introduction to DevOps." You now understand what DevOps is, why it is important, and how it helps teams build better software.
In Module 2, you will learn:
Before you start Module 2, here are some things to think about:
You are doing a fantastic job! Keep learning, keep growing, and we will see you in Module 2! 🚀
© 2026 Certified DevOps Engineer Course • Module 1: Introduction to DevOps
Welcome to Module 9 of our Certified DevOps Engineer course! This module is called "Cloud Platforms & DevOps: Building Software in the Cloud."
In this module, we will learn about Cloud Computing and how it connects with DevOps. We will explore the three biggest cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). We will also learn about the DevOps services they offer.
Think of the cloud like a giant, magical computer that lives on the internet. You can rent space on this computer to run your software without having to buy your own expensive servers. It is like renting a car instead of buying one — you only pay for what you use!
Hello and welcome back! In Module 1, we learned about DevOps. In Module 2, we learned about Git. In Module 3, we learned about Continuous Integration. In Module 4, we learned about Continuous Delivery. In Module 5, we learned about Infrastructure as Code. In Module 6, we learned about containers and Kubernetes. In Module 7, we learned about Monitoring, Logging, and Observability. In Module 8, we learned about DevSecOps and Security. Now, in Module 9, we are going to learn about Cloud Platforms and DevOps.
Imagine you want to build a house. You have two options:
The cloud is like renting space in a giant building filled with computers. You can use as much or as little as you need, and you only pay for what you use.
In this module, we will learn all about cloud platforms — what they are, why they are important, and how they work with DevOps. We will use simple words, fun stories, and lots of examples.
So, are you ready? Let us dive in and discover the amazing world of cloud computing!
By the time you finish this module, you will be able to:
Once upon a time, in a busy city in Nigeria called Lagos, there was a company called "EduApp." They built a learning app for students. The app was very popular, and thousands of students used it every day.
But EduApp had a big problem. They had their own servers in a small room in their office. The servers were old and slow. Sometimes they crashed, and students could not learn. The company spent a lot of money fixing the servers and buying new ones.
One day, a clever engineer named Mr. Emeka said, "Why do we keep buying expensive servers? We should use the cloud!" He explained that the cloud was like renting space on someone else's powerful computers. You only pay for what you use, and you can get more computers instantly when you need them.
Mr. Emeka moved EduApp to AWS (Amazon Web Services), a popular cloud platform. He used EC2 to run the app, S3 to store videos, and CodePipeline to automatically build and deploy new versions.
Now, EduApp never crashes. When thousands of students log in at the same time, the cloud automatically adds more computers to handle the load. The company saves money because they only pay for what they use. EduApp became the most popular learning app in Nigeria.
This story shows us how powerful the cloud can be. It helps companies save money, scale quickly, and focus on building great products. Let us learn more about cloud platforms and how they work with DevOps!
Cloud computing is the practice of using computers and servers that are owned by someone else and accessed over the internet. Instead of buying your own servers, you rent them from a cloud provider.
Cloud computing is important because it makes it easy and cheap to run software. You do not need to buy expensive servers or hire people to maintain them. You can focus on building your product.
Imagine you need electricity for your house. Instead of building your own power plant, you buy electricity from the power company. Cloud computing is like that — instead of building your own computer room, you rent computers from a cloud provider.
A company uses AWS to run their website. They rent virtual computers (EC2 instances) from AWS. They only pay for the time the computers are running. When traffic increases, they start more computers.
Your school rents a bus for a field trip. Instead of buying a bus, they rent one only when they need it. Cloud computing is like renting a bus for your software.
Your family uses a streaming service like Netflix. You do not own the servers that stream the movies. You rent access to them. Cloud computing is like streaming — you use someone else's computers.
A Nigerian bank uses cloud computing to run their mobile app. They rent computers from AWS. They do not need to buy expensive servers. They can focus on building a great app.
CLOUD COMPUTING
TRADITIONAL (Own Servers):
+--------------------------------------------------+
| Buy servers ($10,000 each) |
| Maintain servers (hire staff) |
| Pay for electricity and cooling |
| Upgrade servers every few years |
| 💰 Expensive and complicated |
+--------------------------------------------------+
CLOUD (Rent Servers):
+--------------------------------------------------+
| Rent servers from cloud provider |
| Pay only for what you use (pay-as-you-go) |
| No maintenance needed |
| Scale up or down instantly |
| 💰 Cheap and easy |
+--------------------------------------------------+
Cloud computing is the practice of using computers and servers that are owned by someone else. It is like renting computers instead of buying them. It is cheap, easy, and scalable.
Cloud service models are the different ways you can use the cloud. There are three main models: IaaS, PaaS, and SaaS.
Understanding the different service models helps you choose the right one for your needs. Each model gives you a different level of control.
Imagine you want to eat pizza. You have three options:
| Model | What It Is | What You Control | Analogy |
|---|---|---|---|
| IaaS | Infrastructure as a Service | You control the operating system, apps, and data | Renting a car |
| PaaS | Platform as a Service | You control your apps, but the platform is managed | Using a taxi |
| SaaS | Software as a Service | You control nothing — just use the software | Taking a bus |
A company uses IaaS (AWS EC2) to run their app. They control the operating system and the app. A different company uses PaaS (Google App Engine) to run their app. They just upload their code and the platform runs it. A third company uses SaaS (Gmail) to send email. They just use the software.
IaaS is like being given a room and decorating it yourself. PaaS is like being given a fully furnished room. SaaS is like being given a room with everything already done for you.
IaaS is like having a kitchen and cooking your own meals. PaaS is like having a meal kit delivered. SaaS is like ordering takeout.
A Nigerian startup uses IaaS (AWS) to build their app. They have full control. A Nigerian school uses SaaS (Google Classroom) for online learning. They just use the software.
CLOUD SERVICE MODELS
+--------------------------------------------------+
| IaaS (Infrastructure as a Service) |
| +-------------------------------------------+ |
| | You manage: | |
| | ✅ Applications | |
| | ✅ Data | |
| | ✅ Operating System | |
| | ✅ Runtime | |
| | ❌ Hardware (managed by cloud) | |
| +-------------------------------------------+ |
| |
| PaaS (Platform as a Service) |
| +-------------------------------------------+ |
| | You manage: | |
| | ✅ Applications | |
| | ✅ Data | |
| | ❌ Operating System | |
| | ❌ Runtime | |
| | ❌ Hardware | |
| +-------------------------------------------+ |
| |
| SaaS (Software as a Service) |
| +-------------------------------------------+ |
| | You manage: | |
| | ✅ Use the software | |
| | ❌ Everything else | |
| +-------------------------------------------+ |
| |
| 🔑 More control = more work; less control = less work |
+--------------------------------------------------+
There are three cloud service models: IaaS, PaaS, and SaaS. IaaS gives you the most control (but more work). SaaS gives you the least control (but less work). Choose the right one for your needs.
Amazon Web Services (AWS) is the most popular cloud platform in the world. It was created by Amazon in 2006. AWS has over 200 services that help you build and run software in the cloud.
AWS is important because it is the largest cloud provider. Many companies, including many in Nigeria, use AWS. Learning AWS is a valuable skill for a DevOps engineer.
Imagine AWS is a giant shopping mall for computer services. You can go to different stores to get different things. One store gives you computers (EC2). Another store gives you storage space (S3). Another store gives you databases (RDS). You can pick and choose what you need.
| Service | What It Does | Analogy |
|---|---|---|
| EC2 | Virtual computers (servers) in the cloud | Renting a computer |
| S3 | Storage for files (like documents, images, videos) | A giant hard drive in the cloud |
| RDS | Managed databases | A database that is maintained for you |
| Lambda | Run code without managing servers | A robot that runs your code on demand |
| VPC | Virtual private network for your cloud resources | A private room in the cloud |
| IAM | Manage user permissions | A security guard that controls who can access what |
A company uses AWS to run their website. They use EC2 for servers, S3 for storing images, RDS for the database, and Lambda for background tasks. Everything is managed in the cloud.
Your school uses AWS to store student records (S3), run the school website (EC2), and manage the database (RDS). Everything is in the cloud.
Your family uses AWS to store photos (S3) and run a family website (EC2). Everything is safe and accessible from anywhere.
Flutterwave, a Nigerian fintech company, uses AWS to run their payment platform. They use EC2, RDS, and many other AWS services to handle millions of transactions every day.
AMAZON WEB SERVICES (AWS)
+--------------------------------------------------+
| AWS (A giant mall of cloud services) |
| |
| +-------------------------------------------+ |
| | EC2 (Virtual computers) | |
| | S3 (Storage) | |
| | RDS (Databases) | |
| | Lambda (Serverless code) | |
| | VPC (Networking) | |
| | IAM (Security) | |
| +-------------------------------------------+ |
| |
| All accessible from anywhere! |
| +-------------------------------------------+ |
| | 🌐 Internet | |
| +-------------------------------------------+ |
| | |
| V |
| YOUR APP IS RUNNING! 🚀 |
+--------------------------------------------------+
AWS is the most popular cloud platform. It has over 200 services, including EC2 (computers), S3 (storage), and RDS (databases). Many companies use AWS to run their software.
AWS DevOps services are tools provided by AWS to help you implement DevOps practices. They help you build, test, and deploy software automatically.
AWS DevOps services make it easy to set up CI/CD pipelines in the cloud. You do not need to install and manage your own tools. AWS does it for you.
Imagine you are building a factory. AWS DevOps services are like machines that automatically build, test, and package your products. You just tell them what to do, and they do it.
| Service | What It Does | Analogy |
|---|---|---|
| CodeCommit | Git repository hosted on AWS | A safe place to store your code |
| CodeBuild | Builds your code and runs tests | A machine that builds your product |
| CodeDeploy | Deploys your code to servers | A machine that ships your product |
| CodePipeline | Orchestrates the whole CI/CD pipeline | A conveyor belt in a factory |
| CodeArtifact | Stores and shares artifacts | A warehouse for your products |
A company uses AWS CodePipeline to automate their CI/CD. When a developer pushes code to CodeCommit, CodeBuild builds it, runs tests, and creates an artifact. CodeDeploy deploys it to EC2 servers. The whole process is automatic.
Your school has a system that automatically checks homework when it is submitted. CodeCommit is like the submission system. CodeBuild is like the system that checks the homework. CodeDeploy is like the system that sends the results back.
Your family has an automated system for ordering groceries. CodePipeline is like the whole system. CodeBuild is like checking the order. CodeDeploy is like delivering the groceries.
A Nigerian company uses AWS CodePipeline to deploy their app. They push code to CodeCommit. CodeBuild builds it. CodeDeploy deploys it to EC2 servers. The whole process takes 10 minutes.
AWS DEVOPS PIPELINE
+--------------------------------------------------+
| AWS DEVOPS PIPELINE |
| |
| 1. CodeCommit (Store code) |
| +-------------------------------------------+ |
| | 📂 Source Code | |
| +-------------------------------------------+ |
| | |
| V |
| 2. CodeBuild (Build and test) |
| +-------------------------------------------+ |
| | 🏗️ Build code | |
| | ✅ Run tests | |
| +-------------------------------------------+ |
| | |
| V |
| 3. CodeDeploy (Deploy) |
| +-------------------------------------------+ |
| | 🚀 Deploy to servers | |
| +-------------------------------------------+ |
| | |
| V |
| 🎉 App is live! |
+--------------------------------------------------+
AWS DevOps services include CodeCommit, CodeBuild, CodeDeploy, and CodePipeline. They help you automate your CI/CD pipeline in the cloud. CodePipeline orchestrates the whole process.
Microsoft Azure is the second-largest cloud platform in the world. It was created by Microsoft in 2010. Azure has over 200 services that help you build and run software in the cloud.
Azure is important because it is Microsoft's cloud platform. If you use Microsoft tools (like Windows, Office, or .NET), Azure is a natural choice. Many companies use Azure.
Imagine Azure is another giant shopping mall for computer services, like AWS. It has similar stores (services) but is owned by Microsoft. You can get computers (Virtual Machines), storage (Blob Storage), and databases (Azure SQL) just like in AWS.
| Service | What It Does | Analogy |
|---|---|---|
| Virtual Machines | Virtual computers in the cloud | Renting a computer (like EC2) |
| Blob Storage | Storage for files | A giant hard drive (like S3) |
| Azure SQL | Managed databases | A database that is maintained for you |
| Functions | Run code without managing servers | A robot that runs your code (like Lambda) |
| Azure DevOps | DevOps services (Pipelines, Repos, Boards) | A complete DevOps platform |
A company uses Azure to run their website. They use Virtual Machines for servers, Blob Storage for images, Azure SQL for the database, and Azure DevOps for CI/CD.
Your school uses Azure for their online learning platform. They use Virtual Machines to run the platform and Blob Storage to store videos.
Your family uses Azure to store photos and run a family blog. Everything is secure and accessible from anywhere.
A Nigerian company uses Azure to run their app. They chose Azure because they use many Microsoft tools. Azure integrates well with their existing systems.
MICROSOFT AZURE
+--------------------------------------------------+
| AZURE (Microsoft's cloud platform) |
| |
| +-------------------------------------------+ |
| | Virtual Machines (Computers) | |
| | Blob Storage (Storage) | |
| | Azure SQL (Databases) | |
| | Functions (Serverless code) | |
| | Azure DevOps (CI/CD) | |
| +-------------------------------------------+ |
| |
| All accessible from anywhere! |
| +-------------------------------------------+ |
| | 🌐 Internet | |
| +-------------------------------------------+ |
| | |
| V |
| YOUR APP IS RUNNING! 🚀 |
+--------------------------------------------------+
Microsoft Azure is the second-largest cloud platform. It has services like Virtual Machines, Blob Storage, and Azure DevOps. It is a great choice if you use Microsoft tools.
Azure DevOps is a set of DevOps tools provided by Microsoft. It includes Azure Pipelines (CI/CD), Azure Repos (Git repositories), Azure Boards (project management), and Azure Artifacts (package management).
Azure DevOps is important because it is a complete DevOps platform. You can manage your code, build pipelines, track work, and share artifacts all in one place.
Imagine Azure DevOps is a giant office building for software development. It has offices for writing code (Repos), a factory for building code (Pipelines), a project management room (Boards), and a warehouse for storing finished products (Artifacts). Everything is in one building!
| Component | What It Does | Analogy |
|---|---|---|
| Azure Pipelines | CI/CD pipelines (build, test, deploy) | A factory assembly line |
| Azure Repos | Git repositories for code | A library of code |
| Azure Boards | Project management (tasks, bugs, sprints) | A project planning board |
| Azure Artifacts | Package management (store and share packages) | A warehouse for finished products |
A company uses Azure DevOps for everything. They store code in Azure Repos. They use Azure Pipelines to build and deploy. They use Azure Boards to track tasks. Everything is integrated and organized.
Your school uses Azure DevOps for a project. Azure Repos stores the code. Azure Pipelines builds it. Azure Boards tracks who is doing what. Everything is organized.
Your family uses Azure DevOps to plan a party. Azure Boards tracks the tasks. Azure Repos stores the guest list. Azure Pipelines sends invitations. Everything is automated and organized.
A Nigerian company uses Azure DevOps to manage their software development. They use Azure Boards to track work, Azure Repos for code, and Azure Pipelines for CI/CD. This helps them deliver software faster.
AZURE DEVOPS
+--------------------------------------------------+
| AZURE DEVOPS (Complete platform) |
| |
| +-------------------------------------------+ |
| | Azure Repos (Code storage) | |
| | Azure Pipelines (CI/CD) | |
| | Azure Boards (Project management) | |
| | Azure Artifacts (Package storage) | |
| +-------------------------------------------+ |
| |
| All integrated together! |
| +-------------------------------------------+ |
| | Code → Build → Test → Deploy | |
| | Tracked in Boards | |
| +-------------------------------------------+ |
| |
| 🔑 Everything in one place! |
+--------------------------------------------------+
Azure DevOps is a complete DevOps platform from Microsoft. It includes Azure Pipelines (CI/CD), Azure Repos (code), Azure Boards (project management), and Azure Artifacts (packages). It is all integrated together.
Google Cloud Platform (GCP) is the third-largest cloud platform in the world. It was created by Google in 2008. GCP has over 100 services that help you build and run software in the cloud.
GCP is important because it is Google's cloud platform. If you use Google tools (like Gmail, Google Drive, or Kubernetes), GCP is a natural choice. GCP is also known for its data and machine learning services.
Imagine GCP is another giant shopping mall for computer services, like AWS and Azure. It has similar stores (services) but is owned by Google. You can get computers (Compute Engine), storage (Cloud Storage), and databases (Cloud SQL) just like in AWS and Azure.
| Service | What It Does | Analogy |
|---|---|---|
| Compute Engine | Virtual computers in the cloud | Renting a computer (like EC2) |
| Cloud Storage | Storage for files | A giant hard drive (like S3) |
| Cloud SQL | Managed databases | A database that is maintained for you |
| Cloud Functions | Run code without managing servers | A robot that runs your code (like Lambda) |
| Kubernetes Engine (GKE) | Managed Kubernetes service | A robot that manages containers |
| Cloud Build | Build and test code | A machine that builds your product |
A company uses GCP to run their website. They use Compute Engine for servers, Cloud Storage for images, Cloud SQL for the database, and Cloud Build for CI/CD.
Your school uses GCP for their online learning platform. They use Compute Engine to run the platform and Cloud Storage to store videos.
Your family uses GCP to store photos and run a family blog. Everything is secure and accessible from anywhere.
A Nigerian company uses GCP to run their app. They chose GCP because of its powerful data analytics and machine learning services. They use Compute Engine, Cloud Storage, and Cloud Build.
GOOGLE CLOUD PLATFORM (GCP)
+--------------------------------------------------+
| GCP (Google's cloud platform) |
| |
| +-------------------------------------------+ |
| | Compute Engine (Computers) | |
| | Cloud Storage (Storage) | |
| | Cloud SQL (Databases) | |
| | Cloud Functions (Serverless code) | |
| | Kubernetes Engine (GKE) | |
| | Cloud Build (CI/CD) | |
| +-------------------------------------------+ |
| |
| All accessible from anywhere! |
| +-------------------------------------------+ |
| | 🌐 Internet | |
| +-------------------------------------------+ |
| | |
| V |
| YOUR APP IS RUNNING! 🚀 |
+--------------------------------------------------+
Google Cloud Platform (GCP) is the third-largest cloud platform. It has services like Compute Engine, Cloud Storage, and Cloud Build. It is known for its data and machine learning services.
GCP DevOps services are tools provided by Google Cloud to help you implement DevOps practices. They help you build, test, and deploy software automatically.
GCP DevOps services make it easy to set up CI/CD pipelines in the cloud. They integrate well with other Google services and with Kubernetes.
Imagine you are building a factory. GCP DevOps services are like machines that automatically build, test, and package your products. You just tell them what to do, and they do it.
| Service | What It Does | Analogy |
|---|---|---|
| Cloud Build | Builds your code and runs tests | A machine that builds your product |
| Artifact Registry | Stores and shares artifacts | A warehouse for your products |
| Cloud Run | Runs containerized applications | A machine that runs your containers |
| Kubernetes Engine (GKE) | Managed Kubernetes service | A robot that manages containers |
| Cloud Deployment Manager | Infrastructure as Code | A machine that builds your infrastructure |
A company uses Cloud Build to build their code. Cloud Build runs tests, creates an artifact, and stores it in Artifact Registry. Then Cloud Run deploys the artifact to run the app.
Your school uses Cloud Build to build and test a school project. Cloud Build automatically checks the code and runs tests. Then it deploys the project to a website.
Your family uses Cloud Build to build a family website. Cloud Build checks the code, builds it, and deploys it automatically.
A Nigerian company uses Cloud Build to build their app. They also use Artifact Registry to store artifacts and Cloud Run to run the app. Their CI/CD pipeline is fully automated.
GCP DEVOPS PIPELINE
+--------------------------------------------------+
| GCP DEVOPS PIPELINE |
| |
| 1. Cloud Build (Build and test) |
| +-------------------------------------------+ |
| | 🏗️ Build code | |
| | ✅ Run tests | |
| +-------------------------------------------+ |
| | |
| V |
| 2. Artifact Registry (Store artifacts) |
| +-------------------------------------------+ |
| | 📦 Store packaged code | |
| +-------------------------------------------+ |
| | |
| V |
| 3. Cloud Run (Deploy and run) |
| +-------------------------------------------+ |
| | 🚀 Deploy and run app | |
| +-------------------------------------------+ |
| | |
| V |
| 🎉 App is live! |
+--------------------------------------------------+
GCP DevOps services include Cloud Build, Artifact Registry, Cloud Run, and Kubernetes Engine (GKE). They help you automate your CI/CD pipeline in the cloud and integrate with containers.
A multi-cloud strategy is when a company uses more than one cloud provider. For example, they might use AWS for some services, Azure for others, and GCP for data analytics.
Multi-cloud is important because it gives companies flexibility. They can choose the best service from each provider. They also avoid being locked in to one provider.
Imagine you want to buy groceries. You could go to one store for everything. But instead, you go to one store for fruits, another for vegetables, and another for meat. Each store has the best items. That is a multi-store strategy!
A company uses AWS for their web servers, Azure for their databases, and GCP for machine learning. They use the best service from each provider.
Your school uses different tools for different subjects. Google Classroom for assignments, Microsoft Teams for communication, and Zoom for video calls. That is a multi-tool strategy.
Your family uses different stores for different things. One store for groceries, another for clothes, and another for electronics. That is a multi-store strategy.
A Nigerian company uses AWS for their main application, Azure for their data warehouse, and GCP for their machine learning models. This gives them the best of each provider.
MULTI-CLOUD STRATEGY
+--------------------------------------------------+
| MULTI-CLOUD |
| |
| +-------------------------------------------+ |
| | AWS | |
| | - Web servers (EC2) | |
| | - Storage (S3) | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | Azure | |
| | - Databases (Azure SQL) | |
| | - Analytics (Azure Synapse) | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | GCP | |
| | - Machine Learning (Vertex AI) | |
| | - Container orchestration (GKE) | |
| +-------------------------------------------+ |
| |
| 🔑 Best of each provider! |
+--------------------------------------------------+
A multi-cloud strategy uses more than one cloud provider. It gives you flexibility, avoids vendor lock-in, and lets you choose the best service from each provider.
The benefits of cloud platforms for DevOps are all the good things that happen when you combine cloud computing with DevOps. These include speed, scalability, and cost savings.
Understanding the benefits helps us see why cloud platforms are so important for DevOps. They make DevOps faster, cheaper, and more reliable.
Imagine you are a chef. You have a small kitchen at home (own servers). You can only cook a few dishes at a time. Now imagine you have a giant commercial kitchen with unlimited space and tools (the cloud). You can cook anything, anytime, in any quantity. That is what the cloud does for DevOps!
| Benefit | What It Means |
|---|---|
| Speed | Provision servers in minutes, not days |
| Scalability | Add more servers instantly when needed |
| Cost Savings | Pay only for what you use, no upfront costs |
| Reliability | Cloud providers have backup systems and data centers |
| Global Reach | Deploy applications anywhere in the world |
| Integration | CI/CD tools are built-in (CodePipeline, Azure Pipelines, etc.) |
| Focus | Focus on building your app, not managing servers |
A company uses AWS for their DevOps pipeline. They can deploy new features in minutes. They scale automatically during peak traffic. They save money because they only pay for what they use.
Your school uses a cloud platform for their website. They can add more servers during exam week when traffic is high. They save money when traffic is low.
Your family uses a cloud storage service. You can add more storage when you have more photos. You save money because you only pay for what you use.
A Nigerian company uses AWS for their DevOps pipeline. They deploy new features quickly. They scale during sales events. They save money and grow their business.
BENEFITS OF CLOUD FOR DEVOPS
+--------------------------------------------------+
| |
| ⚡ SPEED |
| Provision servers in minutes |
| |
| 📈 SCALABILITY |
| Scale up or down instantly |
| |
| 💰 COST SAVINGS |
| Pay only for what you use |
| |
| 🔒 RELIABILITY |
| Backup systems and global data centers |
| |
| 🌍 GLOBAL REACH |
| Deploy anywhere in the world |
| |
| 🔧 INTEGRATION |
| Built-in CI/CD tools |
| |
| 🎯 FOCUS |
| Focus on building your app |
| |
| ALL BECAUSE OF CLOUD + DEVOPS! 🎉 |
+--------------------------------------------------+
Cloud platforms offer many benefits for DevOps. They provide speed, scalability, cost savings, reliability, global reach, integration, and the ability to focus on building your app.
In this lesson, we will review everything we have learned about cloud platforms and DevOps. This will help us remember the most important ideas.
Reviewing helps us remember what we have learned. When we keep information in our brains, we can use it later.
Let us think back to everything we have talked about in this module:
A team has learned all these concepts. They use AWS for their infrastructure, Azure for their databases, and GCP for machine learning. They follow DevOps practices and benefit from the cloud.
Your class has learned about cloud platforms. They understand how cloud computing makes software development easier and faster.
Your family has learned about cloud platforms. They understand how cloud services help them store photos, run websites, and use apps.
A Nigerian developer has learned all these cloud concepts. They can now choose the right cloud provider for their projects and use DevOps to build great software.
WHAT WE HAVE LEARNED
+--------------------------------------------------+
| |
| 📌 Cloud = Rent computers over the internet |
| 📌 IaaS, PaaS, SaaS = Service models |
| 📌 AWS = Largest cloud provider |
| 📌 AWS DevOps = CodePipeline, CodeBuild, etc. |
| 📌 Azure = Microsoft's cloud |
| 📌 Azure DevOps = Complete platform |
| 📌 GCP = Google's cloud |
| 📌 GCP DevOps = Cloud Build, Artifact Registry |
| 📌 Multi-cloud = Use multiple providers |
| 📌 Benefits = Speed, scale, cost savings |
| |
| YOU ARE NOW A CLOUD DEVOPS BEGINNER! 🎉 |
| |
+--------------------------------------------------+
We have learned many things about cloud platforms and DevOps. Cloud platforms like AWS, Azure, and GCP help teams build and run software in the cloud. They provide DevOps services that automate building, testing, and deploying software.
Here are the important words we learned in this module. Each word has a simple definition to help you remember it.
| Word | Simple Definition |
|---|---|
| Cloud Computing | Using computers and servers that are owned by someone else, accessed over the internet |
| IaaS | Infrastructure as a Service — rent servers and storage |
| PaaS | Platform as a Service — rent a platform for your apps |
| SaaS | Software as a Service — use software over the internet |
| AWS | Amazon Web Services — the largest cloud platform |
| EC2 | Elastic Compute Cloud — virtual computers in AWS |
| S3 | Simple Storage Service — storage in AWS |
| CodePipeline | AWS CI/CD service that orchestrates building and deploying |
| Azure | Microsoft's cloud platform |
| Azure DevOps | Microsoft's complete DevOps platform |
| Azure Pipelines | CI/CD service in Azure DevOps |
| GCP | Google Cloud Platform — Google's cloud platform |
| Cloud Build | GCP service for building and testing code |
| Multi-Cloud | Using more than one cloud provider |
| Vendor Lock-in | Being dependent on one provider and unable to switch |
Here are the most important concepts from this module. These are the big ideas that will help you understand cloud platforms and DevOps.
Cloud computing is renting computers. Instead of buying your own servers, you rent them from a cloud provider. This is cheaper, easier, and more scalable.
There are three cloud service models. IaaS gives you the most control (servers, storage). PaaS gives you a platform to run your apps. SaaS gives you ready-to-use software.
AWS is the largest cloud provider. It has over 200 services, including EC2, S3, and CodePipeline. Many companies use AWS for their DevOps pipelines.
Azure is Microsoft's cloud platform. It has services like Virtual Machines, Blob Storage, and Azure DevOps. It is a great choice if you use Microsoft tools.
GCP is Google's cloud platform. It has services like Compute Engine, Cloud Storage, and Cloud Build. It is known for its data and machine learning services.
Multi-cloud uses multiple providers. It gives you flexibility, avoids vendor lock-in, and lets you choose the best service from each provider.
Cloud platforms offer many benefits for DevOps. They provide speed, scalability, cost savings, reliability, global reach, integration, and focus on building your app.
Let us look at how to use a cloud platform for DevOps in simple steps:
Decide which cloud provider to use. AWS, Azure, and GCP are the most popular choices. Choose based on your needs, budget, and familiarity.
Sign up for an account with your chosen provider. You will need a credit card for payment, but many providers offer free trials.
Store your code in a Git repository. You can use CodeCommit (AWS), Azure Repos, or Cloud Source Repositories (GCP). Or use GitHub.
Set up a CI/CD pipeline. Use CodePipeline (AWS), Azure Pipelines, or Cloud Build (GCP). Configure it to build, test, and deploy your code.
Deploy your application to the cloud. Use EC2 (AWS), Virtual Machines (Azure), or Compute Engine (GCP). Or use container services like ECS, AKS, or GKE.
Use cloud monitoring services to watch your application. Set up auto-scaling to handle traffic spikes. Use CloudWatch (AWS), Azure Monitor, or Cloud Monitoring (GCP).
STEP-BY-STEP: USING CLOUD FOR DEVOPS
Step 1: CHOOSE PROVIDER
+-------------------+
| AWS, Azure, GCP |
+-------------------+
|
V
Step 2: CREATE ACCOUNT
+-------------------+
| Sign up for |
| cloud account |
+-------------------+
|
V
Step 3: SET UP REPOSITORY
+-------------------+
| Store code in |
| Git repo |
+-------------------+
|
V
Step 4: SET UP CI/CD
+-------------------+
| Create pipeline |
| (Build, test, |
| deploy) |
+-------------------+
|
V
Step 5: DEPLOY APP
+-------------------+
| Deploy to cloud |
| servers |
+-------------------+
|
V
Step 6: MONITOR & SCALE
+-------------------+
| Monitor and |
| scale as needed |
+-------------------+
An e-commerce company uses AWS for their entire infrastructure. They use EC2 for web servers, S3 for images, RDS for the database, and CodePipeline for CI/CD. They deploy new features every week. Their website scales automatically during sales events.
A mobile app team uses Azure DevOps. They store code in Azure Repos. They use Azure Pipelines to build and deploy their app. They use Azure Boards to track tasks. Everything is integrated and organized.
A data analytics company uses GCP. They use BigQuery for data storage, Vertex AI for machine learning, and Cloud Build for CI/CD. They process petabytes of data and deliver insights to their customers.
Flutterwave uses AWS to run their payment platform. They use EC2, RDS, S3, and CodePipeline. Their platform processes millions of transactions every day. The cloud helps them scale and stay reliable.
Paystack uses Azure and GCP for different parts of their infrastructure. They use Azure for their data warehouse and GCP for machine learning. This multi-cloud approach gives them the best of each provider.
A Nigerian tech startup uses AWS for their web app. They use CodeCommit for code, CodeBuild for building, and CodeDeploy for deploying. Their DevOps pipeline is fully automated in the cloud.
You want to start a toy store. You could buy a building (own servers) or rent a space in a mall (the cloud). Renting is cheaper and easier. You can get a bigger space when you have more toys. The cloud is like renting a space in a mall for your software.
You need books for a project. You could buy all the books (own servers) or borrow them from the library (the cloud). Borrowing is cheaper and easier. You can borrow more books when you need them. The cloud is like a library for your software.
You need to go to school. You could buy a car (own servers) or take the bus (the cloud). Taking the bus is cheaper and easier. You can take the bus every day without owning it. The cloud is like taking a bus for your software.
Your family watches movies on Netflix. You do not own the servers that stream the movies. You rent access to them. Cloud computing is like Netflix for your software.
Your family stores photos on Google Photos. You do not own the servers that store the photos. You rent storage space. Cloud computing is like Google Photos for your software.
Your family uses Gmail for email. You do not own the servers that run Gmail. You use it over the internet. Cloud computing is like Gmail for your software.
For Teachers: This module is designed to be accessible for students of all ages. Here are some tips for teaching this module:
For Parents: Your child is learning about cloud platforms and DevOps. Here are some tips to support their learning:
Mistake 1: Using only one cloud provider without consideration.
Using only one provider can lead to vendor lock-in. Consider multi-cloud or hybrid strategies for flexibility.
Mistake 2: Not using cloud-native services.
Cloud providers offer many managed services. Use them instead of building everything yourself. They save time and effort.
Mistake 3: Over-provisioning resources.
Do not provision more resources than you need. Use auto-scaling to handle traffic spikes. You pay for what you use.
Mistake 4: Not using DevOps tools.
Cloud platforms offer DevOps tools like CodePipeline and Azure Pipelines. Use them to automate your CI/CD pipeline.
Mistake 5: Not securing your cloud resources.
Cloud resources need to be secured. Use IAM, network security groups, and encryption to protect your data.
Mistake 6: Not monitoring your cloud resources.
Monitor your cloud resources to catch problems early. Use cloud monitoring services like CloudWatch, Azure Monitor, or Cloud Monitoring.
Choose the right cloud provider.
Choose a provider that meets your needs. Consider cost, services, and location. AWS, Azure, and GCP are all good choices.
Use managed services.
Use managed services like RDS, S3, and Cloud Build. They save time and reduce maintenance overhead.
Automate everything.
Use DevOps tools to automate building, testing, and deploying. This makes your pipeline fast and reliable.
Monitor and optimize.
Monitor your cloud resources and optimize them. Use auto-scaling, right-sizing, and cost management tools.
Secure your resources.
Use IAM, encryption, and network security to protect your resources. Follow security best practices.
Plan for failure.
Design your applications to be resilient. Use multiple availability zones, backups, and disaster recovery.
Use Infrastructure as Code.
Use Terraform or cloud-native IaC tools to manage your cloud resources. This makes your infrastructure repeatable and versioned.
CLOUD SERVICE MODELS
IaaS (Infrastructure as a Service):
+--------------------------------------------------+
| You manage: Apps, Data, OS, Runtime |
| Cloud manages: Hardware |
+--------------------------------------------------+
PaaS (Platform as a Service):
+--------------------------------------------------+
| You manage: Apps, Data |
| Cloud manages: OS, Runtime, Hardware |
+--------------------------------------------------+
SaaS (Software as a Service):
+--------------------------------------------------+
| You manage: Use the software |
| Cloud manages: Everything else |
+--------------------------------------------------+
AWS DEVOPS PIPELINE
+--------------------------------------------------+
| CodeCommit (Store code) |
| +-------------------------------------------+ |
| | 📂 Source Code | |
| +-------------------------------------------+ |
| | |
| V |
| CodeBuild (Build and test) |
| +-------------------------------------------+ |
| | 🏗️ Build code | |
| | ✅ Run tests | |
| +-------------------------------------------+ |
| | |
| V |
| CodeDeploy (Deploy) |
| +-------------------------------------------+ |
| | 🚀 Deploy to servers | |
| +-------------------------------------------+ |
| | |
| V |
| 🎉 App is live! |
+--------------------------------------------------+
MULTI-CLOUD
+--------------------------------------------------+
| AWS |
| +-------------------------------------------+ |
| | Web servers (EC2) | |
| | Storage (S3) | |
| +-------------------------------------------+ |
| |
| Azure |
| +-------------------------------------------+ |
| | Databases (Azure SQL) | |
| | Analytics (Azure Synapse) | |
| +-------------------------------------------+ |
| |
| GCP |
| +-------------------------------------------+ |
| | Machine Learning (Vertex AI) | |
| | Container orchestration (GKE) | |
| +-------------------------------------------+ |
+--------------------------------------------------+
| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| Launched | 2006 | 2010 | 2008 |
| Market Share | Largest (32%) | Second (23%) | Third (10%) |
| Key Strength | Broadest services | Microsoft integration | Data & ML |
| Compute Service | EC2 | Virtual Machines | Compute Engine |
| Storage Service | S3 | Blob Storage | Cloud Storage |
| DevOps Service | CodePipeline | Azure DevOps | Cloud Build |
| Function | AWS | Azure | GCP |
|---|---|---|---|
| Code Repository | CodeCommit | Azure Repos | Cloud Source Repos |
| CI/CD | CodePipeline | Azure Pipelines | Cloud Build |
| Build Service | CodeBuild | Azure Pipelines | Cloud Build |
| Deploy Service | CodeDeploy | Azure Pipelines | Cloud Run |
| Artifact Storage | CodeArtifact | Azure Artifacts | Artifact Registry |
| Project Management | No native tool | Azure Boards | No native tool |
| Aspect | IaaS | PaaS | SaaS |
|---|---|---|---|
| What You Manage | OS, apps, data | Apps, data | Nothing |
| What Provider Manages | Hardware | OS, runtime, hardware | Everything |
| Control Level | High | Medium | Low |
| Example | AWS EC2 | Azure App Service | Gmail |
| Best For | Full control | App development | End users |
Note: Each lesson in this module already includes a "Mini Summary" section right after the lesson content. Please refer back to the lessons above to review each mini summary.
Congratulations! You have completed Module 9 of the "Certified DevOps Engineer" course. Let us review everything we have learned:
Cloud computing is the practice of using computers and servers that are owned by someone else, accessed over the internet. It is like renting computers instead of buying them.
There are three service models: IaaS (Infrastructure), PaaS (Platform), and SaaS (Software). IaaS gives you the most control. SaaS gives you the least control.
AWS is the largest cloud platform. It has services like EC2, S3, and CodePipeline. AWS DevOps services include CodeCommit, CodeBuild, CodeDeploy, and CodePipeline.
Azure is Microsoft's cloud platform. It has services like Virtual Machines and Blob Storage. Azure DevOps is a complete platform with Pipelines, Repos, Boards, and Artifacts.
GCP is Google's cloud platform. It has services like Compute Engine and Cloud Storage. GCP DevOps services include Cloud Build, Artifact Registry, Cloud Run, and GKE.
Multi-cloud uses more than one cloud provider. It gives you flexibility and avoids vendor lock-in. Cloud platforms offer speed, scalability, cost savings, and reliability for DevOps.
You have now completed Module 9! You are ready to move on to Module 10, where you will learn about Exam Preparation and the Capstone Project. Keep up the great work!
Q1: What is cloud computing?
A: Cloud computing is the practice of using computers and servers that are owned by someone else, accessed over the internet.
Q2: What are the three cloud service models?
A: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service).
Q3: What is AWS?
A: AWS (Amazon Web Services) is the largest cloud platform, created by Amazon. It has over 200 services.
Q4: What are AWS DevOps services?
A: AWS DevOps services include CodeCommit (code), CodeBuild (build), CodeDeploy (deploy), and CodePipeline (orchestration).
Q5: What is Azure?
A: Azure is Microsoft's cloud platform. It is the second-largest cloud platform.
Q6: What is Azure DevOps?
A: Azure DevOps is a complete DevOps platform from Microsoft. It includes Azure Pipelines, Azure Repos, Azure Boards, and Azure Artifacts.
Q7: What is GCP?
A: GCP (Google Cloud Platform) is Google's cloud platform. It is the third-largest cloud platform.
Q8: What are GCP DevOps services?
A: GCP DevOps services include Cloud Build (build), Artifact Registry (storage), Cloud Run (run), and GKE (Kubernetes).
Q9: What is multi-cloud?
A: Multi-cloud is a strategy that uses more than one cloud provider. It gives you flexibility and avoids vendor lock-in.
Q10: Is cloud computing used in Nigeria?
A: Yes, many Nigerian companies use AWS, Azure, or GCP. Cloud platforms are helping Nigerian businesses grow and compete globally.
What is cloud computing?
Answer: Cloud computing is the practice of using computers and servers that are owned by someone else, accessed over the internet.
What are the three cloud service models?
Answer: IaaS, PaaS, and SaaS.
What is AWS?
Answer: AWS is the largest cloud platform, created by Amazon.
What does EC2 stand for in AWS?
Answer: Elastic Compute Cloud (virtual computers).
What is S3 in AWS?
Answer: Simple Storage Service (storage for files).
What are AWS DevOps services?
Answer: CodeCommit, CodeBuild, CodeDeploy, and CodePipeline.
What is Azure?
Answer: Azure is Microsoft's cloud platform.
What is Azure DevOps?
Answer: A complete DevOps platform from Microsoft with Pipelines, Repos, Boards, and Artifacts.
What is GCP?
Answer: GCP is Google's cloud platform.
What are GCP DevOps services?
Answer: Cloud Build, Artifact Registry, Cloud Run, and GKE.
What is multi-cloud?
Answer: Using more than one cloud provider.
What is vendor lock-in?
Answer: Being dependent on one provider and unable to switch.
Name two benefits of cloud platforms for DevOps.
Answer: Speed and scalability. (Other answers: cost savings, reliability, global reach, integration, focus.)
Is cloud computing used in Nigeria?
Answer: Yes, many Nigerian companies use AWS, Azure, or GCP.
What is the difference between IaaS and SaaS?
Answer: IaaS gives you infrastructure (servers, storage) to manage. SaaS gives you ready-to-use software over the internet.
Fill in the blanks with the correct words from the list:
Word list: cloud, IaaS, PaaS, SaaS, AWS, Azure, GCP, CodePipeline, Azure DevOps, Cloud Build, multi-cloud, EC2, S3
__________ computing is the practice of using computers and servers that are owned by someone else.
Answer: cloud
__________ gives you infrastructure (servers, storage) to manage.
Answer: IaaS
__________ gives you ready-to-use software over the internet.
Answer: SaaS
__________ is the largest cloud platform.
Answer: AWS
__________ is Microsoft's cloud platform.
Answer: Azure
__________ is Google's cloud platform.
Answer: GCP
__________ is a virtual computer in AWS.
Answer: EC2
__________ is storage in AWS.
Answer: S3
__________ is an AWS service that orchestrates CI/CD pipelines.
Answer: CodePipeline
__________ is Microsoft's complete DevOps platform.
Answer: Azure DevOps
__________ is a GCP service for building and testing code.
Answer: Cloud Build
__________ is a strategy that uses more than one cloud provider.
Answer: multi-cloud
Write True or False for each statement:
Cloud computing is renting computers over the internet.
Answer: True
IaaS gives you the least control.
Answer: False (IaaS gives you the most control)
AWS is the largest cloud platform.
Answer: True
Azure is Google's cloud platform.
Answer: False (Azure is Microsoft's cloud platform)
GCP is Google's cloud platform.
Answer: True
CodePipeline is an AWS DevOps service.
Answer: True
Azure DevOps is a complete DevOps platform from Microsoft.
Answer: True
Cloud Build is an Azure service.
Answer: False (Cloud Build is a GCP service)
Multi-cloud uses more than one cloud provider.
Answer: True
Vendor lock-in is when you can easily switch providers.
Answer: False (Vendor lock-in is when you cannot easily switch providers)
Cloud platforms offer speed and scalability for DevOps.
Answer: True
SaaS gives you the most control over the software.
Answer: False (SaaS gives you the least control)
EC2 is a storage service in AWS.
Answer: False (EC2 is a compute service. S3 is storage.)
Cloud computing is used in Nigeria.
Answer: True
Azure Pipelines is a CI/CD service in Azure DevOps.
Answer: True
Choose the correct answer for each question:
What is cloud computing?
A) Buying your own servers
B) Renting computers over the internet
C) A programming language
D) A video game
Answer: B
What is IaaS?
A) Infrastructure as a Service
B) Information as a Service
C) Internet as a Service
D) Integration as a Service
Answer: A
What is the largest cloud platform?
A) Azure
B) GCP
C) AWS
D) IBM Cloud
Answer: C
What is Azure?
A) Google's cloud platform
B) Amazon's cloud platform
C) Microsoft's cloud platform
D) IBM's cloud platform
Answer: C
What is GCP?
A) Google's cloud platform
B) Amazon's cloud platform
C) Microsoft's cloud platform
D) IBM's cloud platform
Answer: A
What is EC2 in AWS?
A) Storage service
B) Virtual computers
C) Database service
D) Networking service
Answer: B
What is S3 in AWS?
A) Virtual computers
B) Storage service
C) Database service
D) Networking service
Answer: B
What is CodePipeline?
A) An AWS storage service
B) An AWS DevOps service for CI/CD
C) An Azure DevOps service
D) A GCP service
Answer: B
What is Azure DevOps?
A) Google's DevOps platform
B) A complete DevOps platform from Microsoft
C) AWS DevOps
D) A GCP service
Answer: B
What is Cloud Build?
A) AWS DevOps service
B) Azure DevOps service
C) GCP DevOps service
D) A Microsoft service
Answer: C
What is multi-cloud?
A) Using one cloud provider
B) Using more than one cloud provider
C) A type of cloud service model
D) A programming language
Answer: B
What is vendor lock-in?
A) Being able to switch providers easily
B) Being dependent on one provider and unable to switch
C) A type of cloud service
D) A security feature
Answer: B
Which is a benefit of cloud platforms for DevOps?
A) Slower deployment
B) Scalability
C) Higher costs
D) Less reliability
Answer: B
Is cloud computing used in Nigeria?
A) No
B) Yes, by many companies
C) Only in Lagos
D) Only by the government
Answer: B
What is the difference between IaaS and SaaS?
A) IaaS is software; SaaS is infrastructure
B) IaaS gives you control; SaaS gives you ready-to-use software
C) There is no difference
D) IaaS is cheaper than SaaS
Answer: B
Match the words in Column A with their correct meanings in Column B.
| Column A | Column B |
|---|---|
| 1. Cloud Computing | A. Microsoft's cloud platform |
| 2. IaaS | B. Google's cloud platform |
| 3. PaaS | C. Renting computers over the internet |
| 4. SaaS | D. Infrastructure as a Service |
| 5. AWS | E. Platform as a Service |
| 6. Azure | F. Software as a Service |
| 7. GCP | G. Amazon's cloud platform |
| 8. CodePipeline | H. AWS DevOps service for CI/CD |
| 9. Azure DevOps | I. Microsoft's complete DevOps platform |
| 10. Cloud Build | J. GCP DevOps service for building code |
Answers:
What is cloud computing and why is it useful?
Answer: Cloud computing is the practice of using computers and servers that are owned by someone else, accessed over the internet. It is useful because it is cheap, easy, and scalable. You do not need to buy expensive servers. You only pay for what you use.
Explain the difference between IaaS, PaaS, and SaaS.
Answer: IaaS (Infrastructure as a Service) gives you infrastructure like servers and storage to manage. PaaS (Platform as a Service) gives you a platform to run your apps. SaaS (Software as a Service) gives you ready-to-use software over the internet. IaaS gives you the most control. SaaS gives you the least control.
Describe the AWS DevOps services.
Answer: AWS DevOps services include CodeCommit (Git repository), CodeBuild (build and test), CodeDeploy (deploy), and CodePipeline (orchestrates the whole CI/CD pipeline). These services help you automate building, testing, and deploying software in AWS.
What is Azure DevOps and what does it include?
Answer: Azure DevOps is a complete DevOps platform from Microsoft. It includes Azure Pipelines (CI/CD), Azure Repos (Git repositories), Azure Boards (project management), and Azure Artifacts (package management). It is all integrated together.
What is multi-cloud and why is it used?
Answer: Multi-cloud is a strategy that uses more than one cloud provider. It is used to get the best service from each provider, avoid vendor lock-in, optimize costs, and improve resilience. It gives companies flexibility and choice.
A Nigerian startup is growing rapidly. Their app is getting more users every day. They have their own servers in their office, but they are running out of space and power.
Question: How could cloud computing help this startup?
Answer: Cloud computing could help by providing unlimited, scalable resources. The startup could move their app to a cloud platform like AWS, Azure, or GCP. They could use EC2 (or Virtual Machines) for servers and scale up automatically when traffic increases. They would only pay for what they use, saving money.
A company takes days to deploy new features. They have a manual process that is slow and error-prone. They want to automate their deployment.
Question: How could cloud DevOps services help this company?
Answer: Cloud DevOps services could help by automating the entire deployment process. They could use CodePipeline (AWS), Azure Pipelines, or Cloud Build (GCP). Every time a developer pushes code, the pipeline would automatically build, test, and deploy the code. This would make deployments fast and reliable.
A Nigerian bank wants to use a multi-cloud strategy. They want to use AWS for their web app, Azure for their data warehouse, and GCP for machine learning.
Question: What are the benefits of this multi-cloud approach?
Answer: The benefits of this multi-cloud approach include: getting the best service from each provider (AWS for web, Azure for data, GCP for ML), avoiding vendor lock-in, improving resilience (if one provider goes down, others are still working), and optimizing costs.
Instructions:
Instructions:
Why do you think cloud computing is so popular?
Discuss with your classmates and share your ideas.
Have you used any cloud services? What were they?
Share your experiences and thoughts.
What are some other situations where renting is better than buying?
Think about school, home, and other activities.
Do you think multi-cloud is always better than using one provider? Why or why not?
Share your opinions and listen to what others think.
Can you think of a Nigerian company that uses cloud computing?
Share examples of companies in Nigeria.
What do you think is the most important cloud service for DevOps?
Explain why you think so.
Do you think cloud computing is easy to learn? Why or why not?
Share your thoughts.
What is the most important thing you learned about cloud platforms today?
Share with the class.
Goal: Create a simple guide to teach beginners about cloud platforms and DevOps.
Instructions:
Goal: Learn about real-world cloud provider usage.
Instructions:
Scenario:
You are a cloud architect at a Nigerian company. The company has 25 developers working on a large web application. They want to use a cloud platform to improve their DevOps pipeline.
The company has:
Challenge: Create a complete cloud implementation plan for this company. Include:
BONUS CHALLENGE: Present your plan to the class as if you were presenting it to the company's management.
Multiple Choice Questions (Section 28):
True or False Exercises (Section 27):
Fill-in-the-Blank Exercises (Section 26):
Matching Exercises (Section 29):
Congratulations! You have completed Module 9: "Cloud Platforms & DevOps." You now understand how cloud platforms like AWS, Azure, and GCP help teams build and run software in the cloud with DevOps practices.
In Module 10, you will learn:
Before you start Module 10, here are some things to think about:
You are doing a fantastic job!
Certified DevOps Expert · Beginner track
Welcome, young explorer! In Module One, you learned that DevOps is like a bridge between people who build software (developers) and people who run it (operations). In this module, we will learn the tools and habits that make DevOps work like magic. We will talk about automation, CI/CD (Continuous Integration and Continuous Delivery), monitoring, and infrastructure as code.
Imagine you are the captain of a spaceship. You do not want to press 100 buttons every second — you want autopilot! That is what DevOps tools do: they help you automate boring, repetitive jobs so you can focus on building cool stuff. By the end of this module, you will understand how teams use these superpowers to release new features fast, safely, and without breaking things.
We will use stories, drawings, and examples from school, home, and even Nigeria. Ready? Let's go! 🚀
Once upon a time in a small town, there was a pizza shop called "DevOps Pizza". The chef (developer) made delicious pizza recipes, and the delivery riders (operations) delivered them hot. But every day, they had a big problem: the chef would write a new recipe, but the riders did not know how to cook it. And when the riders tried, they sometimes burnt the pizza! 😱
Then, a wise girl named Ayo said: "Why don't we write the recipe in a way that both the chef AND the rider can understand? And why not use a machine that automatically cooks the pizza every time we change the recipe?"
So they built a pipeline — a magical conveyor belt. When the chef updates the recipe, the machine grabs it, bakes it, tests it, and boxes it. Then the rider just delivers it. No more burnt pizzas! That is exactly what DevOps does for software. This module is all about that magical pipeline. 🍕
Definition: Automation means using machines or code to do repetitive tasks without a human pressing buttons every time.
Why important: It saves time, reduces mistakes, and makes people happy because they can do creative work.
Simple: Like a robot that brushes your teeth while you sing.
Real-life: Washing machine — you put clothes in, press start, and it does the rest.
School: A teacher uses a computer to grade multiple-choice tests automatically.
Home: A thermostat that turns on the AC when it gets hot — you don't have to check it every minute.
Nigerian example: In Lagos, some banks use automated teller machines (ATMs) to give cash. You don't need to talk to a teller for small withdrawals.
+-------------------+
| Manual way | → many mistakes, slow
+-------------------+
⬇
+-------------------+
| Automation | → fast, accurate, repeatable
+-------------------+
Mini summary: Automation is like having a helpful robot that does boring jobs so you can focus on fun stuff.
Definition: CI stands for Continuous Integration – developers merge their code many times a day. CD stands for Continuous Delivery – the code is always ready to go live.
Why important: It makes releasing new features fast and safe.
Simple: Like a slide in a playground: you go up the stairs (write code), slide down (test & build), and land in the sand (deploy).
Real-life: A bakery that bakes bread every hour – fresh bread all day.
School: A class project where each student adds a slide, and the teacher checks it immediately so the whole presentation is always ready.
Home: A family calendar where everyone adds events, and the calendar automatically updates on everyone's phone.
Nigerian example: A fintech startup in Abuja uses CI/CD to push new mobile money features every week – they test automatically so customers don't lose money.
+---------+ +---------+ +---------+ +---------+
| Write | -> | Build | -> | Test | -> | Deploy |
| code | | (compile)| | (auto) | | (live) |
+---------+ +---------+ +---------+ +---------+
CI ~~~~~~~~~~~~~~~~~~~~~~~~ CD
Mini summary: CI/CD is a conveyor belt that takes code from a developer's computer to the users, automatically checking it at every step.
Definition: Writing configuration files that describe your servers, networks, and storage – just like code.
Why important: You can create the same environment again and again without clicking in a dashboard.
Simple: Like a LEGO instruction booklet – you follow it to build the same castle every time.
Real-life: A recipe for jollof rice – if you follow it, you get the same delicious rice every time.
School: A science experiment worksheet – every student follows the same steps and gets the same result.
Home: A packing list for vacation – you check the same items every trip.
Nigerian example: A Nigerian cloud provider uses IaC to spin up new servers for Nollywood streaming services during big movie releases.
+------------------+
| main.tf | (Terraform file)
| resource "aws_instance" "web" {
| ami = "ami-123"
| instance_type = "t2.micro"
| }
+------------------+
⬇
+------------------+
| Server created | (exactly the same every time)
+------------------+
Mini summary: IaC means you write down how your servers should look, and a tool builds them automatically.
Definition: A system that tracks changes to files – like a time machine for your code.
Why important: You can go back to any previous version, and many people can work together without stepping on each other's toes.
Simple: Like saving your game progress – if you die, you can reload from the last save.
Real-life: Google Docs – you can see who made which changes and restore older versions.
School: A group project saved on OneDrive – everyone can edit and see history.
Home: A family photo album – you can see how everyone grew over the years.
Nigerian example: A team in Enugu building an e‑commerce app uses Git to manage their code – they have a main branch and feature branches.
+---------+ +---------+ +---------+
| Commit | -> | Commit | -> | Commit |
| (v1) | | (v2) | | (v3) |
+---------+ +---------+ +---------+
⬇ ⬇ ⬇
[main branch] [feature/x] [hotfix]
Mini summary: Git is like a magic notebook that remembers every change and lets you jump to any page.
Definition: Tools that take your source code and turn it into an executable program (or package).
Why important: They make sure your code is correctly formatted and all dependencies are included.
Simple: Like a blender that mixes fruits into a smoothie – you put in ingredients, and it gives you a drink.
Real-life: A factory that assembles car parts into a finished car.
School: A science fair – you gather materials (code) and build a volcano (program).
Home: Making a sandwich – you combine bread, cheese, and ham into a meal.
Nigerian example: A startup in Ibadan uses Maven (Java build tool) to compile their banking app before deployment.
+------------+ +------------+ | source | -> | build tool | -> | .jar / .exe | | code | | (compile) | | (ready to run)| +------------+ +------------+
Mini summary: Build tools turn your code into a working program that users can run.
Definition: A container is like a lightweight box that holds your app and everything it needs to run.
Why important: It works the same on any computer – no more "it works on my machine" excuses.
Simple: Like a lunchbox – you put your meal inside, and it stays fresh and separate from others' food.
Real-life: Shipping containers – they can be loaded on ships, trains, or trucks, and the goods inside stay safe.
School: A pencil case – you keep all your pencils, eraser, and ruler together.
Home: A toolbox – all your screwdrivers and nails are in one box.
Nigerian example: A Lagos fintech uses Docker containers to run their payment gateway – it runs the same in their test lab and on the cloud.
+-------------------+ | Docker container | | +-------------+ | | | App | | | | libraries | | | | config | | | +-------------+ | +-------------------+
Mini summary: Containers are portable boxes for apps – they work everywhere, just like a lunchbox.
Definition: A tool that manages many containers – it starts, stops, and scales them automatically.
Why important: When you have hundreds of containers, you need a "manager" to keep them healthy.
Simple: Like a school bus driver – they pick up all the kids (containers) and take them to the right class (service).
Real-life: Air traffic control – they guide many planes so they don't crash.
School: A teacher managing group activities – they make sure every group has what they need.
Home: A parent coordinating chores – one child washes dishes, another sweeps.
Nigerian example: A large Nigerian telecom uses Kubernetes to manage their customer portal containers during peak call times.
+-----------------------+ | Kubernetes cluster | | +----+ +----+ | | | c1 | | c2 | ... | | +----+ +----+ | | [load balancer] | +-----------------------+
Mini summary: Orchestration is like a conductor for an orchestra of containers – they play in harmony.
Definition: Monitoring means watching your app's health (CPU, memory, errors). Alerts notify you when something is wrong.
Why important: You want to fix problems before users notice – like a smoke alarm at home.
Simple: Like a fitness tracker that tells you if your heart rate is too high.
Real-life: A car dashboard – when the fuel light glows, you know to fill up.
School: A teacher taking attendance – they know if someone is missing.
Home: A baby monitor – you hear if the baby cries.
Nigerian example: A Nigerian e‑commerce site monitors its checkout service – if it slows down, they get an SMS alert and fix it immediately.
+---------+ +---------+ +---------+ | App | --> | Monitor | --> | Alert | | metrics | | (Grafana)| | (email) | +---------+ +---------+ +---------+
Mini summary: Monitoring keeps an eye on your app and shouts if something goes wrong.
Definition: Tools that automatically set up and configure servers (install packages, start services).
Why important: Instead of logging into each server manually, you run a script that does it all.
Simple: Like a magic wand – you wave it, and all the computers in your school get the same software.
Real-life: A school principal that makes sure every classroom has the same textbooks.
School: A lab assistant installing the same software on 20 computers at once.
Home: A robot that cleans all rooms in your house with the same vacuum pattern.
Nigerian example: A Nigerian healthtech company uses Ansible to configure 50 new servers for a telemedicine platform.
+--------+ +--------+ +--------+ | Playbook| --> | Server1| --> | Server2| | (YAML) | | config | | config | +--------+ +--------+ +--------+
Mini summary: Configuration management tools let you set up many servers with one click.
Definition: DevOps is not just tools – it’s a way of working where developers and operations talk to each other often.
Why important: When people share ideas, they build better software and avoid blame games.
Simple: Like a sports team – players pass the ball and cheer each other.
Real-life: A band – each musician plays their instrument, but they listen to each other.
School: A group project where everyone shares their part and helps others.
Home: Family dinner – everyone shares what happened during the day.
Nigerian example: In a Nigerian bank, developers and network engineers have daily stand-up meetings to discuss deployments.
+--------+ +---------+
| Dev | <-> | Ops |
| team | | team |
+--------+ +---------+
\ /
\ /
+----------+
| shared |
| goals |
+----------+
Mini summary: DevOps culture means everyone works together like a family, not like strangers.
Definition: Adding security checks early in the pipeline – not at the end.
Why important: It's cheaper and safer to find bugs before they reach users.
Simple: Like wearing a helmet before you ride a bicycle – you don't put it on after you fall.
Real-life: Airport security – they check bags before people board the plane.
School: Checking your homework for spelling mistakes before submitting.
Home: Locking your front door when you leave – you don't wait until you come back.
Nigerian example: A Nigerian fintech scans their code for vulnerabilities every time a developer pushes code – they call it "shift-left security".
+--------+ +---------+ +--------+ | Code | --> | Security| --> | Deploy | | commit | | Scan | | (safe) | +--------+ +---------+ +--------+
Mini summary: DevSecOps means we think about security from the very beginning.
Definition: Recording events that happen in your app – like a diary.
Why important: When something goes wrong, logs help you find the cause.
Simple: Like writing down what you ate for breakfast – you can check later why you felt sick.
Real-life: A flight recorder in an airplane – it records everything for investigation.
School: A library checkout log – you know who borrowed which book.
Home: A savings book – you record every deposit and withdrawal.
Nigerian example: A Nigerian logistics company logs every delivery attempt – if a package is lost, they check the logs.
2026-07-13 10:00:23 User 123 logged in 2026-07-13 10:01:10 User 123 placed order #456 2026-07-13 10:05:45 Payment failed – insufficient balance
Mini summary: Logs are your app's memory – they tell you what happened and when.
| Word | Simple definition |
|---|---|
| Automation | Making machines do tasks without human help. |
| CI/CD | Continuous Integration / Continuous Delivery – a pipeline that tests and releases code fast. |
| Container | A lightweight package that holds an app and everything it needs. |
| Orchestration | Managing many containers automatically (like a conductor). |
| Infrastructure as Code | Writing files that describe your servers, instead of clicking in a GUI. |
| Monitoring | Watching your app's health and performance. |
| Logging | Recording events that happen in your app. |
| Pipeline | A series of automated steps that code goes through from commit to deploy. |
9:00 AM Code commit 9:01 AM Build starts 9:03 AM Tests run 9:05 AM Security scan 9:07 AM Image built 9:09 AM Deploy to staging 9:12 AM Manual approval 9:15 AM Deploy to production 9:17 AM Monitor for 5 min 9:22 AM All green ✅
| Traditional | DevOps |
|---|---|
| Developers and operations are separate | One team works together |
| Manual deployments (risky) | Automated pipelines (safe) |
| Long release cycles (months) | Short cycles (hours/days) |
| Big bang releases | Small, frequent releases |
In this module, you learned that DevOps is powered by automation, CI/CD, containers, orchestration, monitoring, and collaboration. You saw how these tools work together like a pizza pipeline. You also learned that security and logging are important parts of the process. Remember: DevOps is not just for big companies – even small teams in Nigeria use it to build amazing apps. You are now ready to start thinking like a DevOps engineer!
| Term | Description |
|---|---|
| 1. Git | A. Manages containers |
| 2. Docker | B. Version control |
| 3. Kubernetes | C. Container runtime |
| 4. Jenkins | D. CI/CD server |
| 5. Terraform | E. Infrastructure as Code |
Answers: 1-B, 2-C, 3-A, 4-D, 5-E
Scenario 1: Your team deploys a new feature every Friday, but users report bugs. What DevOps practice would you suggest to reduce bugs?
Scenario 2: A Nigerian bank wants to deploy new ATM software without downtime. Which DevOps strategy can help?
Scenario 3: Your app crashes suddenly. You need to find out why. Which tools do you use?
In groups of 4, act out a DevOps pipeline. One person is the developer (writes code on paper), one is the CI server (builds and tests), one is the deployer (moves the paper to "production"), and one is the monitor (watches for errors). Do three rounds, each time adding a new step.
Draw a DevOps pipeline on a piece of paper with at least 5 stages. Label each stage and write one sentence about what happens there.
Build a Simple CI/CD Pipeline (simulated): Using paper cards, create a physical pipeline. Each card represents a stage: Commit, Build, Test, Deploy, Monitor. Move a "code" card through the stages and discuss what happens at each stage. Add a "security" card.
Install Git on your computer (with parent/teacher help). Create a repository, add a file called "hello.txt" with your name, commit it, and push it to GitHub. Share the link with your instructor.
Write a simple YAML pipeline (pseudo-code) with at least 4 stages: build, test, deploy, monitor. You can use any names you like. Explain each stage in one sentence.
In Module Three, we will dive into hands-on tools – you will learn how to write a simple Dockerfile, run containers, and even create a basic Kubernetes pod. Make sure you have a computer with internet access and your curiosity ready! We will also explore more Nigerian DevOps success stories.
© 2026 · Certified DevOps Expert · Module Two · Beginner friendly 🎉