UNIT - III (Introduction to project management):
1.The need for source code control
2.The history of source code management
3.Roles and code
4.source code management system and migrations
5.Shared authentication,
6.Hosted Git servers
7.Different Git server implementations
8.Docker intermission
9.Gerrit
10.The pull request model
11.GitLab.
The need for source code control
For the purpose of devops, in fact almost everything can be expressed in a codified form, including the following
• The applications that we build
• The infrastructure that hosts our application
• The documentation that documents our products
Even the hardware that runs our applications can be expressed in the form of software.
Source code control (also known as version control or revision control) is a vital component of modern software
development. Here are some reasons why source code control is necessary:
Collaboration: In software development, multiple developers often work on the same codebase at the same time.
Source code control enables developers to work collaboratively on the same codebase, without risking conflicts or
overwriting each other's changes.
Versioning: Source code control provides a version history of the codebase, allowing developers to track changes over
time and easily revert to previous versions if necessary.
Backup and recovery: Source code control serves as a backup of the codebase, helping developers to recover lost or
deleted files or code.
Code quality: Source code control enables developers to review code changes and ensure that changes meet quality
standards and do not introduce new bugs or errors.
Branching and merging: Source code control enables developers to create branches to work on new features or bug
fixes without disrupting the main codebase. When the work is complete, branches can be merged back into the main
codebase.
In summary, source code control is essential for effective collaboration, versioning, backup and recovery, code quality,
and branching and merging in modern software development.
The history of source code management
To understand the central need for source code control, it is helpful to briefly examine the history of the
development of source code management.
This gives us vision into the features we need.
Some examples are as follows:
1.Storing historical versions of source in separate archives
This is a very simple form, and it still lives on to some extent, with many free software projects offering tar
Archives of older releases to download
2.Centralized source code management with check in and check out
In some systems, a developer can lock files for exclusive use.Every file is managed separately.
Tools like this include Revision Control System(RCS) and Source Code Control System(SCCS).
3.A centralized store where you merge before you commit
Examples include Concurrent Version System(CVS) and SubVersion.
Many organizations have centralized workflows, and SubVersion implements such workflows.
Currently Git is the most popular too,but there are many other similar tools in use such as
Bazaar and Mercurial…etc
The history of source code management (also known as version control or revision control) dates back to
the early days of software development. In the 1970s, developers began using basic version control
techniques, such as manually numbering file versions and creating backups on tapes.
In the 1980s, more advanced version control systems were developed, including RCS (Revision Control
System) and SCCS (Source Code Control System). These systems were designed to manage changes to
source code files and allow developers to work collaboratively on the same codebase.
In the 1990s, distributed version control systems were developed, including CVS (Concurrent Versions
System) and Subversion. These systems enabled developers to work on code simultaneously and merge
changes together.
In the 2000s, Git was developed by Linus Torvalds, the creator of Linux. Git revolutionized source code
management by introducing a distributed system that allows developers to work on code offline and
merge changes with other developers when online.
Today, there are many different version control systems available, including Git, SVN, Mercurial, and Perforce. These
systems have become essential tools for software development, enabling teams to collaborate effectively, track changes
to code, and ensure code quality
Roles and code
Form DevOps' point of view, In DevOps, it’s important to make the source code management tool a central meeting
point.
Many different roles need to use source code management.
Developers live and breath source code management. It's their Bread and Butter.
Operations team uses source code management(VCS) to manage the descriptions of infrastructure in the form of
Code, scripts and other artifacts.
Example infrastructural descriptors include network topology,and versions of software that
Should be installed on particular server.
Quality assurance team can store their automated tests in codified form in the source code repository.
Example testing tools are selenium, unit…etc
There is a problem with the documentation of the manual steps needed to perform various tasks.
It is possible to store all documentation in the wiki format in the central source code repository, depending on
the wiki engine used.
Many Git project management systems have this feature now, such as GitLab and GitHub.
Advantages of Version Control System
The following are the advantages of vcs.
1) We can maintain different versions and we can choose any version based on the client requirements.
2) With every version or commit we can maintain meta-data like commit message, who did changes I, when he
did the changes and what he did the changes?
3) RCS/VCS provides the environment for developer to share the source code to the peer developers in very
easy way.
4) Multiple developers can work in collaborative way!
5) Parallel development is possible, so development becomes faster.
6) We can provide access control in version control system like who can read code? who can modify code?
source code management system and migrations
A source code management (SCM) system(example: Git or SVN), is a tool used to manage changes to source code over time.
Migrations refer to the process of moving data from one system to another.
In the context of software development, migrations are commonly used to manage changes to a database schema or to
move data between different environments, such as from a development environment to a production environment.
Choosing a Branching strategy
When working on code that will be deployed to servers ,it's essential for everyone on the team to follow the same branching
strategy.
A branching strategy is a convention or set of rules that describes
when branches are created?
how they are to be named?
what use branches should have?…etc
Example:
This helps make sure that everyone knows:
1.Where to put new features (like a feature branch).
2.Where to put bug fixes that need to go live immediately (often in a separate "hotfix" branch).
3.Which branch is safe to deploy to production.(like master branch)
Branching strategies are important when working with other people, less impotent when you are working on your
Own.
Most source code management systems do not prescribe a particular branching strategy.
A feature or topic branch is a branching strategy that is used to keep track of ongoing development
Regarding a particular feature, bug…etc
Here all changes in the code regarding the feature can be handled together.
There are many well-known branching strategies Vincent Driessen recognized a branching strategy called
“GIT FLOW", which has many good features.
Git flow looks complex, a brief look at what are the branches are for:
The following are some branches
1.Master branch
2.Develop branch
3.Feature branch
4.Hot fix branch
Feature Branch: Used to develop new features without affecting other work.
Bugfix Branch: Used to fix bugs without risking the main codebase.
Hotfix Branch: Used for urgent fixes in production.
• The master branch only contains finished work. All commits are tagged, since they represent releases.
All releases happen from the master branch.
• The develop branch is where developers work on changes and new features that will be included in the next release of
the software. When work is finished here, the develop branch is merged with the master branch.
• We use separate feature branches for all new features. Feature branches are merged to the develop branch.
• When a shocking bug is revealed in production, a hotfix branch is made where a bug fix is created.
the hotfix branch is then merged to the master branch and a new release for production is made.
Branching problem areas
There is a debate between continuous delivery (CD) practices and branching strategies.
Some CD methods sponsor a single master branch and all releases being made from that master branch.
Gitflow is one example of that model.
Problem:
We need to fix a bug in the released code, but the master branch has new features we’re not ready to release yet. This
happens when production updates are slower than the development team's releases. It’s not ideal, but it’s common.
There are 2 basic methods of handling this issue
1.Make a bug fix branch and deploy to production from it:
Here we don’t disrupt the development flow.
this method might require duplication of testing resources.
Example
-----------
Problem: Users aren’t getting notifications for new messages on WhatsApp.
Development Situation: The main codebase (master branch) has a new feature (like "Disappearing Messages after 24 hours")
that’s not ready yet.
Goal: Fix the notification bug without releasing the new feature.
Steps
Create a Hotfix Branch: The team creates a branch called hotfix/notification-bug from the last stable version (the one
currently in production).
Fix the Bug: They fix the notification issue in the hotfix/notification-bug branch and commit the changes.
Deploy the Hotfix: They deploy this hotfix branch to production, so users start receiving notifications again.
The new "Disappearing Messages" feature stays in the master branch and doesn’t go live yet.
Merge Back to Master: After deploying, they merge hotfix/notification-bug back into the master branch to keep everything
up-to-date.
This way, WhatsApp fixes the critical bug without releasing unfinished features to users.
2.Feature toggling:
in this approach, you turn off features that are not yet ready for production.
this way you can release the latest development version.
+-----------------------+
| Master |
| (New Feature) |
+-----------------------+
|
|
+--------------------+
| Production Version | <-- current live version with a bug
+--------------------+
|
|
+--------------------------------+
| Step 1: Create Hotfix Branch |
| Branch from Production version |
+--------------------------------+
|
|
+--------------------------------+
| Step 2: Fix Bug in Hotfix Branch|
+--------------------------------+
|
|
+--------------------------------+
| Step 3: Deploy Hotfix to Production |
+--------------------------------+
|
|
+--------------------------------+
| Step 4: Merge Hotfix Back to Master |
+--------------------------------+
Artifact version naming
Version numbers become important when you have larger installations.
The following are the basic principles of version naming
1.Version numbers should grow monotonically.
2.Versions should be comparable to each other and it should be easy
to see which version is newer
3.Use the same schema for all artifacts
4.This usually translates to a version number with 3 or 4 parts
a. the first is for major changes
b. the second is for minor changes
c. the third is for bug fixes
d. the fourth can be a build number
All installable artifacts have proper release number and a corresponding tag in the
Source code management system.
Choosing client
One of the nice aspects of git is that it doesn’t mandate the use of a particular client.
Most of the clients use one of several core git implementations, which is good for stability and quality.
Most current development environments have good support for using git.
Many developers use the client integrated in their development environments or the command line git client.
When working with operations task, the command-line git client is often preferred because it is convenient
To use when working remotely through SSH shell.
Shared authentication
In most organizations, there is a central server for handling authentication.
Authentication is the process of verifying the identity of a user or system.
An LDAP(Lightweight Directory Access Protocal) server is a system that stores information like user details and access
permissions. It helps organizations to manage and retrieve this data easily, making it simpler to control who can access what
resources.
It is easy to set up an LDAP server for testing purposes.
LDAP (Lightweight Directory Access Protocol) is a commonly used protocol for accessing and managing directory services,
such as user account information and authentication credentials.
LDAP provides a standard way to store and retrieve authentication information, making it an ideal choice for implementing
shared authentication in a DevOps environment.
With LDAP-based authentication, users' authentication credentials are stored in a central directory service, and various
applications and services can authenticate users against this directory using the LDAP protocol.
This enables a single set of authentication credentials to be used across multiple applications and services, simplifying user
authentication and access control.
One advantage of using LDAP for shared authentication is that it provides a centralized repository for authentication
information, which can be easily managed and updated.
This can help improve security by ensuring that authentication policies are consistently enforced across different
applications and services.
To implement LDAP-based authentication in a DevOps environment, an LDAP server must first be set up and
configured with user account information and authentication credentials. Applications and services that support LDAP
can then be configured to authenticate users against this LDAP server.
Hosted Git Servers
Some organizations may not be able to use services hosted by another organization.
These might be government organizations or organizations dealing with money such as banking, insurance
And gaming organizations. The cause might be legal or simply nervousness about letting critical code.
If you have no such fears, it is quite reasonable to use a hosted service, such as GitHub or GitLab, that offers private
accounts.
Using GitHub or GitLab is a convenient way to learn to use Git and explore its possibilities.
It is also quite easy to install a GitLab instance on your organization’s premises.
Some of the features offered by both GitLab and GitHub over Git are as follows:
• Web interfaces
• A documentation facility with an in-built wiki
• Issue tracker
• Commit visualization
• Branch visulalization
• The pull request workflow
There are several hosted Git server options available, each with its own set of features and pricing plans. Here are
some popular ones:
GitHub: It is one of the most popular Git hosting platforms, offering unlimited public repositories and paid plans for
private repositories. It provides features like code review, issue tracking, and project management tools.
GitLab: GitLab is an open-source Git repository management tool that offers both self-hosted and cloud-hosted
options. It offers features like continuous integration/continuous deployment (CI/CD), issue tracking, and project
management tools.
Bitbucket: Bitbucket is a Git hosting service that offers both cloud-hosted and self-hosted options. It offers
unlimited private repositories for small teams and features like pull requests, code reviews, and issue tracking.
GitKraken: GitKraken is a cloud-based Git hosting service that offers features like code review, issue tracking,
and project management tools. It has a free plan for individual users and paid plans for teams.
AWS CodeCommit: AWS CodeCommit is a fully managed Git hosting service provided by Amazon Web
Services (AWS). It offers features like code review, branch management, and access control. It is designed to
integrate with other AWS services like AWS CodePipeline and AWS CodeDeploy.
These are just a few examples, there are many other options available depending on your specific needs and
requirements.
Different Git server implementations
There are several Git server implementations available, each with its own features and benefits. Here are a
few popular ones:
1.GitLab
2.GitHub
3.Bitbucket
4.Gitolite
5.Gitea
GitLab: GitLab is an open-source Git management tool that provides features like code review, issue tracking,
continuous integration and deployment, and more. It can be installed on your own server, or you can use GitLab.com,
a hosted version of GitLab.
GitHub: GitHub is a web-based Git repository hosting service that offers a wide range of features such as code review,
issue tracking, pull requests, and more. It is widely used for open source projects and is owned by Microsoft.
Bitbucket: Bitbucket is a web-based Git repository hosting service that provides features like pull requests, code
review, and issue tracking. It also offers integration with other Atlassian products like Jira and Confluence.
Gitolite: Gitolite is an open-source Git server that provides access control to Git repositories. It allows you to control
who has access to which repositories and what they can do with them.
Gitea: Gitea is a self-hosted Git service that is lightweight and easy to install. It provides features like pull requests,
code review, issue tracking, and more.
These are just a few of the many Git server implementations available. The choice of which one to use depends on
your specific needs and preferences
Docker intermission
Docker is a popular platform for building, shipping, and running applications in containers.
Containers are a lightweight, standalone package of software that includes everything
needed to run an application, such as code, libraries, and dependencies.
Docker provides a way to package and distribute applications in containers, which makes it
easier to deploy and manage applications across different environments.
Docker consists of two main components: the Docker engine and the Docker client.
The Docker engine is responsible for running containers and managing their lifecycle, while
the Docker client provides a command-line interface for interacting with the Docker
engine.
Docker images are the building blocks of containers. An image is a read-only template that
includes instructions for creating a container, such as the operating system, libraries, and
dependencies needed for the application to run.
Docker images can be built from scratch or based on existing images, which can be
downloaded from Docker Hub, a registry for Docker images.
Docker containers are instances of Docker images that are running in an isolated environment.
Each container has its own file system, networking, and process space, which makes it possible to run multiple
containers on the same host without them interfering with each other. Containers can be started, stopped, and
restarted using the Docker engine.
Docker provides many benefits for developers and operations teams, including portability, scalability, and
reproducibility. By packaging applications in containers, developers can ensure that they run the same way in any
environment, from development to production. Operations teams can use Docker to automate the deployment and
management of applications, which can save time and reduce errors.
To get started with Docker follow thdnfe following steps
1.Install docker according to the particular instructions for your os.
for redhat use the following command
dnf install docker
To run docker use the following command
systemct1 enable dockersystemct1 start docker
2.We need another tool, Docker Compose.
To install Docker compose visit the following website
https://docs.docker.com/compose/install/
Docker Compose is used to automatically start several Docker-packaged applications such as a
Database sever a webserver.
Gerrit
Gerrit is a web-based code review and project management tool for software development.
It was developed by Google and is used by many other large software companies, including Android,
Eclipse, and Wikimedia.
Gerrit provides a platform for developers to submit their code changes for review by their peers.
These code changes are organized into a series of commits, which can be reviewed and discussed by
other developers.
The goal of Gerrit is to improve code quality and increase collaboration among team members.
Gerrit is built on top of the Git version control system and provides many features that are specifically
designed for code review, such as inline commenting, diff viewing, and merge conflict detection.
It also integrates with many popular development tools, such as Jenkins and GitHub.
Gerrit can be downloaded as a Java WAR file and it has an integrated setup method.
It needs a Relational database as a dependency.
Generally we will use Java based H2 database along with Gerrit.
To run Gerrit instance with Docker,use the following steps
1.Initialize and start Gerrit
docker run –d –p 8080:8080 –p 29418:29418 openfronttier/gerrit
2.Open your browser and type the following URL at browser Windows's addressbar
http://<docker host url>:8080
Installing the git-review package
Install git-review on your local installation
sudo dnf install git-review
the above command install a helper application for Git to communicate with Gerrit.
It adds a new command git-review,that is used instead of git push to push changes to the
Gerrit git server
The value of history revisionism
When we work with code together with other people in ateam,the code’s history becomes more important
Than when we work on our own.
This is especially important when workinh with code review and code review tools such as gerrit.
The code changes also need to be easy to understand.
Example:
Consider a case where you made a number of changes and later changed your mind and removed them.
Another case is when you have a set of omits that are easier to understand if they are a single commit.
Adding commits together is called “Squashing” in the git documentation.
Another case that complicates history is when you merge from the upstream central repository several times,
And merge commits are added to the history.
In this case we want to simplify the changes by first removing our local changes, then fetching and
Applying changes from the upstream and then finally, reapplying our local changes.this process
Is called “Rebasing”.
Advantages
The following are the advantages of Gerrit
1.Improved code quality: Gerrit provides a platform for peer review of code changes, which helps to identify and fix
errors and issues early on in the development process. This leads to higher-quality code and a more stable and
reliable software product.
2.Increased collaboration: Gerrit allows team members to review and discuss code changes in a collaborative
environment, leading to better communication and coordination among team members. This can improve the overall
efficiency and effectiveness of the development process.
3.Streamlined workflow: Gerrit integrates with many popular development tools, such as Git, Jenkins, and GitHub,
providing a streamlined workflow for development and code review. This helps to reduce manual effort and increase
productivity.
4.Customizable review process: Gerrit allows teams to customize their code review process based on their specific
needs and requirements. This allows teams to adapt to changing project demands and optimize their development
process.
5.Enhanced security: Gerrit provides several security features, such as access controls, code signing, and user
authentication, to ensure that code changes are secure and meet the organization's standards and policies.
The Pull request Model
The pull request model is a popular approach used in software development for managing changes to a codebase. It is
commonly used in version control systems like Git.
In the pull request model, when a developer wants to make changes to the codebase, they create a new branch off the main
branch (usually called "master" or "main") and make their changes on this branch. Once they have made their changes and
tested them, they create a pull request (also known as a merge request or merge proposal) to ask the team to review and
merge their changes into the main branch.
The pull request includes all the changes made in the branch, along with any .
In this model, pushing to repositories can be disallowed except for the repository owners.
Other developers are allowed to fork the repository, however and make changes in their fork. When they are
Done making changes, they can submit a pull request. The repository owners can then review the request
And opt to pull the changes into master repository.
This model is very easy to understand and many developers have experience in it from the many
Open source projects on git hub.
GitLab
GitLab is a web-based Git repository manager that provides continuous integration, continuous deployment, and other
DevOps services.
It allows developers to collaborate on projects, track bugs, and manage code repositories.
GitLab also offers a wide range of features such as code reviews, issue tracking, and a built-in CI/CD pipeline to automate
the software delivery process.
One of the unique features of GitLab is that it is open-source software and can be self-hosted, meaning that you can
install it on your own servers and have complete control over your data. GitLab also offers a cloud-based version,
GitLab.com, that provides similar functionality without the need for self-hosting.
GitLab has gained popularity among developers due to its ease of use, flexibility, and extensive feature set. It is a powerful
tool for collaboration and code management that is suitable for individual developers as well as large teams.
GitLab can be installed either on-premise (self-hosted) or on a cloud provider such as AWS, Google Cloud, or Azure. Here
are the general steps for installing GitLab on a Linux server:
Install the dependencies: GitLab requires certain dependencies such as Git, Ruby, and a PostgreSQL database. Install
them on your server using your package manager.
Download and install GitLab: You can download GitLab from the GitLab website or use the command line to
download and install the package.
Configure GitLab: Once GitLab is installed, you need to configure it. The configuration file is located in
/etc/gitlab/gitlab.rb. You can set the URL, ports, email configuration, backup settings, and other options in
this file.
Start GitLab: After you have configured GitLab, start the GitLab service using the command sudo gitlab-ctl
start.
Access GitLab: Once GitLab is up and running, you can access it by entering the IP address or domain
name of your server in a web browser. You will be prompted to create a new account and password.
GitLab supports many features on top of Git.
GitLab is a large and complex software system based on Ruby language.
Docker-compose is used to install gitlab.
To start a local gitlab instance use the following steps
mkdir gitlab
cd gitlab
wget
https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
docker-compose up
Here docker-compose command will read the .yml file and start all the required services in a default
Demonstration configuration.
If you read the start up login in the console window,you will notice that 3 separate application containers have
Been started:gitlab postgresql1,gitlab redis1 and gitlab gitlab1.
The gitlab container includes the ruby-based webapplication and Git backend functionality.
Redis is a distributed key-value store and PostgreSQL is realation database.
The docker-compose.yml file sets up data volumes at /srv/docker/gitlab.
To log in to the web user interface, use the administrator password given with the installation
Instructions for the gitlab docker image.
