in the beginning, there was code.
The constant unending flow of hundreds of thousands, and sometimes
even millions of lines of code.
Usually written by programmers and software developers in isolation,
this code was a massive web of complex computing instructions that were
difficult to read and test, let alone extend with additional functionality.
To solve this problem, developers and programmers invented the concept
of what we call modular programming.
Modular programming is a general programming approach that involves
separating a program's functions into independent building blocks.
Each containing all the parts needed to execute a single
aspect of the functionality.
When put together these modules make up the final executable program.
Let's have a look at an example.
Imagine that you are tasked to clean the living room.
A program for cleaning the living room would look something like this.
Program, clean living room.
If there are toys on the floor, remove the toys.
END.
If the rug looks messy, vacuum the rug.
END.
If there are spots on the floor, wipe the floor with a wet mop.
END.
With remove the toys, vacuum the rug and wipe the floor as
different functions of the program.
Each of these functions would require some additional instructions and conditions.
Using the modular approach, we can create a separate independent program, also
known as a module that will house those additional instructions and conditions.
For example, a module for the function vacuum the rug, would
look something like this.
Program, vacuum the rug.
Find the vacuum in the basement.
Check, if the vacuum is charged.
If there is not enough charge, charge the vacuum.
END.
Carry the vacuum to the main floor.
Start the vacuum.
Vacuum a lap around the outside of the rug.
While the rug is not fully vacuumed,
Vacuum a lap around the inside of the previous lap.
END,
Turn off the vacuum.
Move the vacuum to the basement.
END.
Now, if you look carefully at the program, we still have, sub-tasks like
a charge, the vacuum to accomplish, which we can flesh out further.
For example, a module for charging the vacuum would look something like this.
Program, charge the vacuum.
Locate the charger.
Find the available outlet.
Plug the charger in the outlet.
While the vacuum is not fully charged,
Let the vacuum charge.
END.
Remove the charger from the outlet.
Put the charger back where it belongs.
END.
You get the idea.
Here every function is really a series of functions.
Every module can, and often should be broken into smaller modules.
The smallest module with the highest granularity that cannot be broken down
into further modules is called a unit.
To make the programs more robust, extreme programming, which is an Agile
framework, suggest that developers add a few additional lines of
code to these units, to test their functionality right from the get-go.
You might've heard the term unit tests.
This is what it refers to.
Okay.
So modules are like building blocks where each block represents an
independent, robust and testable piece of code that can be stacked together
in the end to create the full product.
This stacking together of different modules is what we call merging
the code or code integration.
Let's walk through an example software development and deployment
process to understand it better.
Imagine that you own an online bookstore where customers can come search for
the favorite book, add the book to the cart, log into their account, pay for
the book and select a shipping method.
Each of these functions of the online bookstore can be
coded separately, as...modules.
Let's also imagine that you outsourced the creation and maintenance of the
online bookstore to an external vendor.
Let's call the vendor EZ!SOFT.
EZ!SOFT, created the bookstore as an online app and then deployed, or in
simple words, installed the app on a cloud service like Microsoft Azure or Amazon
Web Service, popularly known as AWS.
Once deployed the customers of your online bookstore could access it
online through their web browsers.
Now, for us to understand the software development and the deployment
process, we need to zoom into how EZ!SOFT creates the software.
For simplicity's sake, let's imagine that EZ!SOFT is an Agile vendor
that creates a software using scrum.
They have a product owner and three different scrum teams.
Each scrum team is responsible for creating and maintaining
separate independent modules of the online bookstore software.
Team 1 is responsible for the search and add to cart module.
Team 2 is responsible for the login module.
And team 3 is responsible for payment and shipping module.
The EZ!SOFT product owner talks to the customer, which in this case is YOU!
And gathers all the requirements.
With the help of the scrum master the product owner, then converts
these requirements into user stories.
These user stories are then stored in a convenient product backlog,
which the team, then prioritize and estimate to create a release plan.
I've already covered, prioritizing and estimating the user stories
and creating a release plan in a different tutorial series.
You can find the link to the series, in this corner.
Okay.
After creating the release plan, the three teams select the work they need to
work on during a sprint planning meeting.
During the sprint, each of the three teams that checks the code, they
created into a separate folder, also known as a repository, which
is a specific to each module.
These repositories are located within what we call a source control system,
which is nothing but a software tool that manages code check-ins.
The source control system is installed on a separate dedicated machine.
The most common and popular source control systems include
AWS Codecommit, Microsoft's Team Foundation Server, GitHub, IBM's
Clear Case, BitBucket and Subversion.
Besides the three scrum teams, EZ!SOFT also has a dedicated integration
team and a dedicated operations team.
The integration team owns the working and maintenance of the source control system.
This team is responsible for merging also called integrating all of the
work from the 3 teams, into one code.
They do it once at the end of each sprint.
The integrated code is stored in a separate folder called
the mainland repository within the source control system.
After merging the code, the integration team then builds the code.
Now, what do I mean by building the code?
The source code that the integration team receives from the development
teams is not machine-readable.
Computers only understand the language of zeros and ones.
The integrated source code is in human readable language.
Code-building, or building the code is done by a build tool that converts
or compiles this human readable source code into zeros and ones.
The source code converted into zeros and ones is called the
executable code or compiled code.
The integration team then sends this executable code as a compressed file
it to the operations team, along with the instructions to deploy,
or in simple words, install the software to various environments.
Environments like dev test environment for QA to do all sorts of end to end tests.
To a staging environment for user acceptance testing And finally,
when all the tests are done to the production environment.
Once available to the production environment, the product or the
product update is available for the end users or customers to use.
This is the typical process that most Scrum teams follow
in various organizations.
There are many problems with this process, though.
In the upcoming videos, we will see what those problems are and
how the practices like continuous integration and continuous delivery,
can help us solve those problems.
If you liked this video, then give it a thumbs up subscribe,
and don't forget to provide your valuable feedback in the comments.
I'll see you in the next video.