UNIT-III

INTRODUCTION TO PROJECT MANAGEMENT

DevOps project management is a union between the two disciplines where project management is
tailored to and supports the DevOps model. In a DevOps project management approach, project
managers serve as coordinators between multiple contributors and as trackers of timelines and
dependencies.
However, project managers also need to be closely aligned with the DevOps team and bring a deep
understanding of the development process and skills needed to create the end product. There are several
best practices that project managers should follow to achieve this integration with the DevOps pipeline.
Everything is code, and you need somewhere to store it. The organization's source code management
system is that place. Developers and operations personnel share the same central storage for their
different types of code. There are many ways of hosting the central code repository:
• You can use a software as a service solution, such as GitHub, Bitbucket, or GitLab. This can be
cost-effective and provide good availability.
• You can use a cloud provider, such as AWS or Rackspace, to host your repositories.
• Some types of organization simply can't let their code leave the building. For them, a private in-
house setup is the best choice.

3.1 THE NEED FOR SOURCE CODE CONTROL

Terence McKenna, an American author, once said that everything is code. While one might not agree
with McKenna about whether everything in the universe can be represented as code, for DevOps
purposes, indeed nearly everything can be expressed in codified form, including the following:
• The applications that we build.
• The infrastructure that hosts our applications.
• The documentation that documents our products.
• Even the hardware that runs our applications can be expressed in the form of software.
Given the importance of code, it is only natural that the location that we Place code, the source code
repository, is central to our organization. Nearly everything we produce travels through the code
repository at some point in its life cycle.
In today's fast-paced software development environment, DevOps has emerged as a leading approach
that enables faster and more reliable software delivery. DevOps brings together development and
operations teams, automating the entire software development lifecycle, from code development to
deployment and operations. However, for DevOps to be successful, it requires a robust source code
control (SCC) mechanism.
Source code control, also known as version control or revision control, is a crucial aspect of software
development and collaboration. It refers to the process of managing and tracking changes to the source
code files. SCC provides a centralized repository for storing and managing the source code, allowing
developers to track changes, collaborate, and maintain version control. The need for Source code control
in DevOps arises due to several reasons:
• Versioning and History: 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.

1
 • Collaboration and Teamwork: 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.
• Code Integrity and Safety: Source code control systems ensure the integrity and safety of the
codebase. By using a centralized repository, developers can prevent accidental loss or corruption
of code. If mistakes are made, it is possible to revert to a previous working version. Additionally,
source code control allows for branching and merging, enabling developers to experiment with
new features or fixes without affecting the main codebase until they are ready.
• Bug Tracking and Issue Management: Source code control can integrate with issue tracking
systems, allowing developers to link code changes to specific bugs or issues. This integration
streamlines the development process by providing traceability between code changes and the
problems they address. It improves collaboration between developers and testers and speed up
finding and solving issues.
• Continuous Integration and Deployment: Source code control systems play a crucial role in
enabling continuous integration and deployment (CI/CD) practices. By automating the build, test,
and deployment processes, developers can ensure that changes in the codebase are thoroughly
tested and deployed to production efficiently.
• Code Reusability and Collaboration: Source code control allows developers to share code and
collaborate on reusable components. By organizing code into libraries, modules, or packages, it
becomes easier to reuse existing functionality across projects, saving development time and
effort.
• 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.
Overall, source code control is essential for efficient and collaborative software development. It ensures
the integrity and safety of the codebase, facilitates teamwork and collaboration, enables versioning and
history tracking, supports CI/CD practices, and promotes code reusability and code quality through
processes like code reviews.

2
Source Code Control Management Tools:
• Git
• Helix Core
• Subversion
• ClearCase
• Team Foundation Server
• Mercurial.
Components of Source Code Control:
source code control involves the following key components

• Repository: A central repository serves as the primary storage for the source code files and their
associated version history. It can be hosted locally or remotely and can be accessed by multiple
developers or teams.
• Versioning: Source code control systems keep track of changes made to code files over time.
Each change is recorded as a version or revision, capturing the modifications, author, timestamp,
and a description of the changes. This versioning enables developers to understand the evolution
of the codebase and easily switch between different versions when necessary.
• Branching and Merging: Source code control allows developers to create branches, which are
separate lines of development that diverge from the main codebase. Branches enable developers
to work on different features, bug fixes, or experiments independently. Once the changes are
complete, they can be merged back into the main codebase, combining the modifications from
different branches.
• Concurrency and Conflict Resolution: When multiple developers are working on the same
codebase concurrently, conflicts may arise when attempting to merge changes. Source code
control systems provide mechanisms to identify and resolve conflicts by highlighting conflicting
changes and allowing developers to review and reconcile them manually.
• Access Control: Source code control systems offer access control mechanisms to regulate who
can view, modify, and contribute to the codebase. Access permissions can be defined at the
repository, branch, or file level, ensuring that only authorized individuals have the appropriate
privileges.
• Collaboration and Communication: Source code control systems often provide tools and
features to facilitate collaboration and communication among team members. This includes
features like code reviews, issue tracking integration, commenting on specific code sections, and
notifications to keep developers informed about code changes.
3
Popular source code control systems include Git, Mercurial, and Subversion, among others. These
systems provide a command-line interface as well as graphical user interfaces and integrate with various
development tools and platforms.
In summary, source code control is a systematic approach to managing and tracking changes to source
code files. It offers versioning, branching, merging, conflict resolution, access control, and collaboration
features, enhancing productivity, code integrity, and teamwork in software development projects.
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 that development becomes faster.
6. We can provide access control in version control system like who can read code? who can modify
code?

3.2 THE HISTORY OF SOURCE CODE MANAGEMENT

The history of source code management dates back several decades, evolving alongside the development
of software engineering practices. Here is a brief overview of the major milestones in the history of
source code management:
Early Version Control Systems (VCS): In the 1970s, developers began using rudimentary version
control systems to manage source code. These systems relied on simple methods like copying files to
different directories with version numbers or using shell scripts to track changes.
Separate Archives for Versions: The earliest form of managing code involved storing different versions
of the source code in separate archives. This method is still used by some free software projects, which
offer older versions.
Centralized Management with Check-In/Check-Out: This approach allowed developers to lock files
for exclusive use. Here, each file is managed independently with tools like RCS (Revision Control
System) and SCCS (Source Code Control System). These tools are rarely used today, but some of the
parts can still be found in file headers indicating past management by RCS.
SCCS and RCS: The Source Code Control System (SCCS) was developed in the late 1970s by Marc
Rochkind at Bell Labs. SCCS introduced the concept of storing changes as differences or patches,
enabling efficient storage of multiple versions of files. It provided basic version control capabilities but
lacked network support. Later, the Revision Control System (RCS) was developed as an open-source
alternative to SCCS, adding support for multiple users and network access.
Centralized Version Control Systems (CVCS): In the 1980s and 1990s, centralized version control
systems became popular. These systems using server/client model, it utilized a central repository to store
the entire history of the codebase. systems maintain one copy of a project on a centralized server to
which all code changes are committed. Developers would check out specific files from the repository,
make modifications, and check them back in, but never have a full copy of the project locally. Notable
examples include Concurrent Versions System (CVS) and later, Subversion (SVN). CVCS offered
improved collaboration and versioning capabilities compared to earlier systems.
4
Distributed Version Control Systems (DVCS): The rise of distributed version control systems
revolutionized source code management. Distributed version control systems allow developers to clone
the repository to their own local server or machine so they have the complete history of the project.
When they’re done with their changes, they commit them to their local source code repository, then
“push” this local repository code to the master repository. Distributed Version Control is a version
control where each client can have same copy of source code as server has and both server and client
maintain history of source code. In 2005, Linus Torvalds created Git, which quickly gained popularity
and became the de facto standard for many developers. Git introduced a distributed model where every
local copy of the repository contained the full history. Git is most popular tool, but many other similar
tools in use, such as Mercurial and Bazaar.
Hosted Version Control Platforms: With the growth of cloud computing, hosted version control
platforms emerged. These platforms, such as GitHub, GitLab, and Bitbucket, provided web-based
interfaces for managing Git repositories. They offered additional collaboration features like issue
tracking, pull requests, code reviews, and integrations with other development tools. Hosted platforms
facilitated social coding, open-source collaboration, and enabled seamless teamwork across distributed
teams.
Advanced Version Control Workflows: Over time, developers and teams adopted more advanced
version control workflows to accommodate complex development scenarios. Examples include feature
branching workflows, Gitflow, and trunk-based development. These workflows introduced practices like
branch management, release management, and continuous integration and deployment, enabling
streamlined and efficient software development processes.
The history of source code management has seen a progression from manual and simplistic methods to
sophisticated distributed version control systems and collaborative platforms. These advancements have
significantly improved the productivity, collaboration, and quality of software development projects.
Difference between Centralized Version Control and Distributed Version Control:
Following are the important difference between Centralized Version Control and Distributed Version
Control.
Key Centralized Version Control Distributed Version Control
Working In CVS, a client need to get local copy of In DVS, each client can have a local branch as
source from server, do the changes and well and have a complete history on it. Client
commit those changes to central source need to push the changes to branch which will
on server. then be pushed to server repository.
Learning CVS systems are easy to learn and set up. DVS systems are difficult for beginners.
Curve Multiple commands need to be remembered.
Branches Working on branches in difficult in CVS. Working on branches in easier in DVS.
Developer often faces merge conflicts. Developer faces lesser conflicts.
Offline CVS system do not provide offline DVD systems are workable offline as a client
Access access. copies the entire repository on their local
machine.
Speed CVS is slower as every command need to DVS is faster as mostly user deals with local
communicate with server. copy without hitting server every time.
Backup If CVS Server is down, If DVS server is down, developer can work
developers cannot work. using their local copies.

5
3.3 ROLES AND CODE
In DevOps, roles and code play a critical role in the development, delivery, and operation of software.
Roles: In DevOps, a source code management tool serves as a central meeting point for various roles
within a project. There are many different roles, each role interacts with the tool in different ways:
• Developers: They rely heavily on source code management for writing and updating code. It is
a crucial part of their daily work.
• Operations Personnel: They manage infrastructure through code in the form of code, scripts,
and other artifacts. Such infrastructural descriptors include network topology and specifying
software versions for different servers.
• Quality Assurance (QA) Personnel: They use the source code repository to store automated
tests created. with tools like Selenium and Junit.
There is a problem with the documentation of the manual steps needed to perform various tasks. This is
more of a psychological or cultural problem than a technical one. It is possible to store all documentation
in the wiki format in the central source code repository, depending on the wiki engine used. This makes
documentation hard to find and use for some roles and easy for others. Many Git project management
systems have this feature now, such as GitLab and GitHub.
In source code management (SCM), various roles and responsibilities are involved in managing and
controlling the source code. Here are some common roles and their associated tasks in SCM, along with
the types of code typically handled by each role:
1. SCM Administrator: The SCM administrator is responsible for managing the overall source
code management system. They configure and maintain the SCM tools, set up user access
controls, and ensure the availability and integrity of the source code repository.
2. Repository Manager: The repository manager is in charge of managing the source code
repository. They create and organize code repositories, establish branching and merging
strategies, and handle backups and recovery processes. They may also define code review
workflows and manage code quality.
3. Developer: Developers are responsible for writing and modifying the source code. They use
version control tools to check out code, make changes, and commit their changes back to the

6
 repository. Developers collaborate with their team members, resolve merge conflicts, and ensure
code quality through best practices such as code reviews and testing.
4. Release Manager: The release manager coordinates the process of releasing software versions.
They create release branches, tag specific versions of the code, and manage the release pipeline.
Release managers ensure that the correct code is deployed to various environments and work
closely with developers and other stakeholders to plan and execute releases.
5. Build Engineer: The build engineer is responsible for the automated build and compilation
processes. They set up build configurations, define build scripts, and ensure that the code can be
built successfully from the repository. Build engineers also handle dependency management and
artifact generation.
6. Quality Assurance (QA) Engineer: QA engineers focus on testing the code for quality and
ensuring that it meets the required standards. They may develop and execute test scripts, perform
regression testing, and collaborate with developers to resolve any code-related issues.
Code:
• Code is the backbone of DevOps and represents the software that is being developed, tested,
deployed, and maintained.
• Code is managed using source code control systems like Git, which provide a way to track
changes to the code over time, collaborate on the code with other team members, and automate
the build, test, and deployment process.
• Code is continuously integrated and tested, ensuring that any changes to the code do not cause
unintended consequences in the production environment.
In conclusion, both roles and code play a critical role in DevOps. Teams work together to ensure that
code is developed, tested, and delivered quickly and reliably to production, while operations teams
maintain the code in production and respond to any issues that arise.
Overall, Source Code Management (SCM) has been an important part of the evolution of DevOps,
enabling teams to collaborate, manage code changes, and automate the software delivery process.
3.4 SOURCE CODE MANAGEMENT SYSTEM AND MIGRATIONS
Selecting Source Code Management System:
• There are many source code management (SCM) systems out there, and their development will
continue because SCM is crucial in software development.
• Among the available systems, Git is considered as the dominant system currently.
• Git was created by Linus Torvalds to manage the development of the Linux kernel without
considering BitKeeper which was a previously used proprietary system. Git was designed to
handle the complex workflow of Linux kernel development and is robust for most organizations.
• The primary benefit of Git versus older systems is that it is a distributed version control system
(DVCS). There are many other distributed version control systems, but Git is the most pervasive
one.
Distributed version control systems apart from Git include the following:
• Bazaar: This is abbreviated as bzr. Bazaar is endorsed and supported by Canonical, which is the
company behind Ubuntu. Launchpad, which is Canonical's code hosting service, supports Bazaar.
• Mercurial: Notable open source projects such as Firefox and OpenJDK use Mercurial. It
originated around the same time as Git.

7
 • Git can be complex, but it makes up for this by being fast and efficient. It can be hard to
understand, but that can be made easier by using frontends that support different tasks.
Distributed Version Control Systems (DVCS) advantages:
✓ Offline Work: DVCS allows developers to work offline and independently on their local
repositories. This is particularly beneficial in situations where there is limited or no network
connectivity. Developers can commit changes, create branches, and perform other version control
operations locally without needing a connection to a central server.
✓ Collaboration and Parallel Development: DVCS enables parallel development by allowing
multiple developers to work on the same project simultaneously. Each developer can have their
own local repository, create branches, make changes, and merge them back to the main
repository. This fosters collaboration and reduces conflicts that often arise in centralized systems
where developers need to wait for each other to make changes.
✓ Flexibility and Branching: DVCS provides greater flexibility in branching and merging.
Developers can easily create branches for new features, bug fixes, or experiments without
disrupting the main codebase. Multiple branches can exist concurrently, and merging changes
between branches is typically simpler and more efficient in DVCS.
✓ Speed and Performance: DVCS is often faster and more performant compared to centralized
systems, especially for common operations like committing changes, switching branches, or
viewing revision history. This is because these operations can be performed locally on the
developer's machine without relying on network communication with a central server.
✓ Redundancy and Backup: With DVCS, every developer has a full copy of the entire project's
history and codebase. This redundancy acts as a built-in backup mechanism, providing additional
protection against data loss or corruption. If a central server goes down or is compromised,
developers can still retrieve the entire history from their local repositories.
✓ Flexibility in Workflow: DVCS allows teams to adopt different workflow models, such as
Gitflow, Feature Branching, or Forking Workflow, to suit their specific development processes
and requirements. This flexibility supports agile development practices and encourages efficient
collaboration within the team.
Overall, the advantages of distributed version control systems contribute to increased developer
productivity, improved collaboration, and greater flexibility in managing codebases and development
workflows.
Migrations:
• SCM migration is not just about switching from one version control system to another. It's an
opportunity to correct old inconsistencies or challenges and implement modern and collaborative
workflows to make the developer's work easier.
• Migrating from one source code management system (SCM) to another involves transferring the
existing codebase, including the version history and associated metadata, to the new system while
ensuring data integrity and minimizing disruptions to the development team.
• Relocating from Subversion to Git is one example of a straightforward migration. Under these
circumstances, it is not necessary to compromise accuracy of historical data.
• Here are a few key considerations and best practices when undertaking a source code
management system migration:

8
 1. Thorough planning: Proper planning is essential to ensure a smooth migration process. Start by
defining clear objectives, understanding the reasons for the migration, and establishing a timeline
and budget. Identify potential risks and develop contingency plans to address them.
2. Selecting the right target system: Evaluate and select a suitable target SCM system that aligns
with your requirements, taking into account factors such as scalability, integrations with other
tools, ease of use, and support for your development workflows.
3. Preparing the codebase: Before the migration, clean up and organize the codebase to minimize
any unnecessary baggage. Remove unused or obsolete code, ensure consistent file and folder
structures, and resolve any outstanding issues or conflicts.
4. Data migration strategy: Determine the most appropriate method to migrate the codebase and
version history to the new SCM system. Options may include exporting and importing
repositories, using migration tools, or writing custom scripts. Ensure that the migration process
preserves commit history, branches, tags, and any associated metadata.
5. Communication and training: Inform and involve the development team throughout the
migration process. Communicate the reasons for the migration, address concerns, and provide
training on the new SCM system to ensure a smooth transition. Consider organizing workshops
or documentation to assist with onboarding and provide ongoing support.
6. Testing and validation: Perform thorough testing and validation of the migrated codebase to
ensure that all versions, branches, and tags are correctly transferred. Test common SCM
operations and integrations with other tools or systems to ensure functionality and compatibility.
7. Rollback plan: Despite careful planning, unexpected issues may arise during the migration.
Develop a rollback plan to revert to the original SCM system if necessary. This plan should
include steps to back up the original codebase and define criteria for deciding when to trigger the
rollback.
8. Post-migration clean-up: After the migration is complete, conduct a post-migration review to
identify any issues or gaps. Clean up any artifacts, remnants, or redundant data left behind during
the migration process.
9. Change management: Change management processes should be in place to handle the transition
and address any challenges or resistance from the development team. Provide ongoing support
and monitor the adoption and usage of the new SCM system to address any issues or gaps.
Choosing a branching strategy:
Branching is a fundamental concept in version control systems, including Git. It allows developers to
create separate lines of development within a codebase, enabling multiple concurrent workflows and
isolating changes from the main codebase until they are ready to be integrated. A branching strategy is
a convention, or a set of rules, that describes when branches are created, how they are to be named, what
use branches should have, and so on.
Key Aspects of Branching:
• Purpose of Branching Strategies: These strategies are crucial for collaborative work. They
ensure that everyone on the team follows the same rules thereby reducing conflicts and confusion.
Even when working alone, having a branching strategy helps in maintaining organized and
manageable code.
• Flexibility of SCM Tools: Many source code management (SCM) systems, including Git, do not
impose a particular branching strategy. They provide the basic mechanics for branching, leaving
it up to the team to decide how to use them.
9
 In distributed version control systems like Git, creating and working with feature branches (also
known as topic branches) is usually straightforward and cost-effective. These branches allow
developers to work on specific features or bugs independently, without affecting the main
codebase.
• Popular Branching Strategies:
✓ Git Flow: This is a well-known strategy formalized by Vincent Driessen. It includes
multiple branches such as master, develop, feature, release, and hotfix. While Git Flow
offers many benefits, some may find it very complex and hence prefer simplified
versions.
✓ Scaled-down Models: For teams that find Git Flow too complicated, there are simpler
versions. available that retain the core benefits but reduce the complexity.

• Structure in Git Flow: This strategy helps maintain a clear and organized workflow, ensuring
that development progresses smoothly and that the main codebase remains stable.
✓ Master Branch: It contains only the work which is completed. Each commit is tagged
because it represents a release. All production releases happen from the master branch.

10
 ✓ Develop Branch: It involves developers work on changes and new features that will be
included in the next release of the software. Once the work is completed, the develop
branch is merged into the master.
✓ Feature Branches: It associates à distinct feature branch for every new feature. All these
features are then merged to develop branch.
✓ Release Branches and Hotfixes: Release branches prepare for a new production release,
while hotfix branches address critical bugs that need immediate attention. When a
devastating bug is revealed in production, a hotfix branch is made where a bug fix is
created. The hotfix branch is then merged to master, and a new release for production is
made.
Git flow is a centralized pattern, and as such, it's reminiscent of the workflows used with Subversion,
CVS, and so on. The main difference is that using Git has some technical and efficiency-related
advantages.
Another strategy, called the forking pattern, where every developer has a central repository, is rarely
used in practice within organizations, except when, for instance, external parties such as subcontractors
are being employed.
Branching problem areas:
While branching is a powerful feature in version control systems, it can introduce certain challenges and
problem areas if not managed effectively. Here are some common issues that can arise when working
with branches:
1. Branch Overload: Having too many branches can lead to confusion and complexity. If branches
are not properly managed, it becomes difficult to track the purpose and status of each branch. It's
important to establish clear guidelines and conventions for branch naming, usage, and lifecycle
management.
2. Long-Lived Branches: Branches that exist for an extended period can become divergent from
the main codebase, making it harder to merge changes back. Frequent merges from the main
branch into long-lived branches and keeping them up to date can help mitigate this issue.
3. Merge Conflicts: When multiple developers make changes to the same files or code sections,
merge conflicts can occur when trying to merge branches together. Resolving conflicts can be
time-consuming and requires careful attention to ensure the merged code maintains its integrity.
Regular communication and coordination among team members can help reduce the occurrence
of conflicts.
4. Delayed Integration: If branches are kept isolated for too long without regular integration with
the main branch, it becomes difficult to detect and resolve integration issues. Delayed integration
can lead to more significant conflicts and challenges when merging changes. Encouraging
frequent integration, preferably through continuous integration practices, can help avoid this
problem.
5. Lack of Visibility and Communication: When working with multiple branches, it's important
to maintain good communication and visibility among team members. Lack of communication
about branch status, changes, or conflicts can result in duplication of work, wasted effort, or
misunderstandings. Tools like issue trackers, pull requests, and regular team meetings can
facilitate better communication and collaboration.
6. Inconsistent Branching Strategies: Inconsistent usage of branching strategies within a team or
across projects can lead to confusion and difficulties in managing the codebase. It's important to
11
 establish and document a clear branching strategy that aligns with the team's development
process and goals.
7. Unmerged or Abandoned Branches: Over time, branches may become unmerged or
abandoned, resulting in unused or obsolete code. Cleaning up such branches regularly can help
maintain a clean and manageable codebase.
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.
3.5 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 Protocol) 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.
For learning purposes, setting up a test LDAP server, like the: 389 Server along with the phpLDAPadmin
web application, can be useful. This setup allows users to manage user authentication across different
servers under use.
By implementing shared authentication in SCM, organizations can achieve several benefits:
✓ Centralized User Management: Shared authentication allows for centralized user management,
making it easier to add, update, or remove user accounts across the organization's systems.
✓ Consistent Access Control: Users' access to repositories, branches, or specific actions in the
SCM system can be managed centrally through the IdP (Integration with Identity Providers),
ensuring consistent access control policies and reducing administrative overhead.

12
 ✓ Improved Security: Shared authentication can enhance security by leveraging the IdP's robust
authentication mechanisms, including multi-factor authentication, password policies, and
account recovery processes.
✓ Streamlined Onboarding: New team members can quickly gain access to the SCM system by
leveraging their existing credentials from the IdP, simplifying the onboarding process.
To implement shared authentication in SCM, organizations should choose an SCM system that supports
integration with popular IdPs or SSO solutions. Configuration settings and authentication options within
the SCM system need to be properly set up to establish the trust relationship and enable secure
communication with the IdP.
Overall, shared authentication in SCM enhances user experience, simplifies user management, and
strengthens security by leveraging a centralized authentication mechanism.

3.6 HOSTED GIT SERVERS

Some organizations, like government organizations or organizations dealing with money, such as bank,
financial institutions, insurance, and gaming organizations prefer not to use external services for hosting
their code due to legal or security concerns. For those who can use external services, platforms like
GitHub or GitLab are popular choices. These platforms offer features such as private repositories, issue
tracking, and commit visualization. They are great for learning and exploring Git capabilities.
GitHub and GitLab both offer free accounts to get started, making it easy to evaluate their services and
determine what is needed for the projects. They also provide additional features beyond basic Git, like
web interfaces and documentation facilities. Some of the features offered by GitHub and GitLab are.
✓ Use of web interfaces
✓ Documentation facility with an inbuilt wiki
✓ Use of issue trackers
✓ Commit visualization
✓ Branch visualization
✓ The pull request workflow.
While these are all useful features, it's not always the case that you can use the facilities provided. For
instance, you might already have a wiki, a documentation system, an issue tracker, and so on that you
need to integrate with. The most important features we are looking for, then, are those most closely
related to managing and visualizing code.
There are several popular 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 and Mercurial-based 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.

13
 • Git Kraken: Git Kraken 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 Code Commit: AWS Code Commit 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 Code Pipeline and
AWS Code Deploy.
These are just a few examples, there are many other options available depending on your specific needs
and requirements.
key features of GitLab and GitHub: Both GitLab and GitHub offer a range of features that make them
popular choices for hosting Git repositories and collaborating on code. Here are some key features
offered by both platforms:
1. Repository Hosting: Both GitLab and GitHub allow you to create and host Git repositories for
your projects. You can clone, push, and pull code using Git commands and access your
repositories securely.
2. Issue Tracking: Both platforms provide built-in issue tracking systems that allow you to create,
manage, and track issues or bugs related to your codebase. You can assign issues, set priorities,
add labels, and create custom workflows to streamline your development process.
3. Pull Requests and Code Review: GitLab and GitHub support pull requests, which enable
developers to propose code changes, review them, and merge them into the main branch. You
can leave comments, discuss changes, and ensure code quality before merging.
4. Collaboration and Team Management: Both platforms offer collaboration features like team
management, user permissions, and access controls. You can invite team members, assign roles,
and define user permissions to control access to repositories and project resources.
5. Continuous Integration and Deployment (CI/CD): GitLab and GitHub provide CI/CD
capabilities to automate building, testing, and deploying your applications. You can define
pipelines and configure triggers to execute various actions, such as running tests, building
artifacts, and deploying to production environments.
6. Project Management and Boards: Both platforms include project management tools, such as
kanban boards, for visualizing and managing tasks and workflows. You can create and organize
project boards, track progress, and manage your development process.
7. Integrations and Marketplace: GitLab and GitHub offer integrations with various third-party
tools and services. They have marketplaces with a wide range of extensions, plugins, and
integrations to enhance your development workflow and integrate with popular services like Jira,
Slack, and Docker.
It's worth noting that while GitLab offers many of these features as part of its core offering, GitHub
provides some advanced features, such as code scanning, security vulnerability alerts, and code spaces,
through its paid plans or separate add-ons.
3.7 DIFFERENT GIT SERVER IMPLEMENTATIONS
There are several Git server implementations available, each with its own unique features and benefits.
Here are a few popular Git server implementations:
1. GitLab
2. GitHub
14
 3. Bitbucket
4. Gitolite
5. Gitea
6. RhodeCode
7. SCM Manager
GitLab: GitLab is not only a hosted git platform but also an open-source Git management tool that
provides features like code review, issue tracking, continuous integration and deployment, and more. It
provides a complete DevOps platform with features like repository hosting, issue tracking, continuous
integration/continuous deployment (CI/CD), project management, 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 Server, formerly known as Stash, is the self-hosted version of Atlassian's Bitbucket
platform. Bitbucket is a web-based Git and Mercurial repository hosting service that provides features
like pull requests, code review, issue tracking and project management. It also offers integration with
other Atlassian products like Jira and Confluence.
Gito lite: Gito lite 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 offers a simple and
intuitive user interface, along with features like repository management, issue tracking, pull requests,
user management and more. Gitea is designed to be easy to set up and suitable for small to medium-
sized projects or personal use.
RhodeCode: RhodeCode is an enterprise-grade, self-hosted Git server implementation. It offers features
such as code collaboration, access controls, code review, issue tracking, and CI/CD integration.
RhodeCode aims to provide a secure and scalable solution for organizations that require fine-grained
permissions and advanced repository management.
SCM Manager: SCM Manager is an open-source Git server implementation that supports other version
control systems like Subversion and Mercurial as well. It provides a web-based interface for repository
management, user access control, and basic project management features. SCM Manager is known for
its simplicity and ease of use.
These are just a few of the many Git server implementations available. Depending on your specific
requirements and preferences, you can choose the one that best suits your needs in terms of features,
scalability, security, and integration capabilities.

3.8 DOCKER INTERMISSION

Docker is a powerful tool that allows packaging of applications in containers, making it easier to deploy
and manage applications across different environments. By doing so, users can quickly and easily set up
different Git servers, test their functionalities, and decide which one is well-suited for the organization.
Docker simplifies these deployments. allowing to focus on evaluating the server features rather than the
complexities of manual setup.
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.
15
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 the following steps:
1. Install Docker according to the operating system's instructions. For Red Hat-based systems, this
can be done using the command, dnf install docker-io.
2. To run docker use the following command
o systemctl enable docker
o systemctl start docker
3. 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.
Docker benefits include:
• High ROI (Return on Investment) and cost savings
• Productivity and standardization
• Maintenance and compatibility
• Rapid deployment
• Faster configurations
• Seamless portability
• Continuous testing and deployment
• Isolation, segregation, and security

3.9 GERRIT
Gerrit is a web-based code review tool, which is integrated with Git and built on top of Git version
control system (helps developers to work together and maintain the history of their work). It allows
merging changes to Git repository when you are done with the code reviews. It ensures that every piece
of code is reviewed by others, which helps maintain high code quality.
Gerrit allows developers to submit code changes in the form of patches or commits for review. Other
team members can then review the changes, add comments, and suggest improvements. The code review

16
process in Gerrit facilitates collaboration and ensures that code changes meet the project's standards and
guidelines.
Gerrit integrates closely with Git. It allows developers to push changes to a special review branch. When
the changes are approved through Gerrit's review process, they can be merged into the main branch.
Gerrit was developed by Shawn Pearce at Google which is written in Java, Servlet, GWT(Google Web
Toolkit). The stable release of Gerrit is 2.12.2 and published on March 11, 2016 licensed under Apache
License v2.
Why Use Gerrit? Following are certain reasons, why you should use Gerrit.
• You can easily find the error in the source code using Gerrit.
• You can work with Gerrit, if you have regular Git client; no need to install any Gerrit client.
• Gerrit can be used as an intermediate between developers and git repositories.
Key features of Gerrit:
1. Code review workflow: Gerrit provides a structured workflow for code reviews, allowing
reviewers to provide feedback, discuss changes, and make decisions on whether the code changes
should be accepted or rejected.
2. Access controls: Gerrit offers fine-grained access controls, allowing project owners to define
who can submit changes, review code, and merge code into the main repository. This helps
maintain security and ensures that only authorized individuals can make changes to the codebase.
3. Integration with Git: Gerrit integrates seamlessly with Git repositories, allowing developers to
push their changes for review directly from their local Git client. It provides a web interface for
reviewing and managing code changes.
4. Commenting and discussion: Reviewers can add comments directly on specific lines of code,
suggesting improvements or pointing out issues. Discussions can take place within the context
of the code changes, enabling effective collaboration and communication.
5. Continuous Integration (CI): Gerrit can be integrated with CI systems, such as Jenkins, to
automatically trigger tests and build processes when code changes are submitted for review. This
helps ensure that code changes are thoroughly tested before they are merged.
Overall, Gerrit improves the code review process and facilitates better collaboration among developers
working on the same project. It helps maintain code quality, reduces the risk of introducing bugs, and
ensures that the codebase is kept in a stable and maintainable state.
This tool is particularly useful in projects that require rigorous code reviews and where maintaining high
code quality is crucial.
Gerrit instance can be run with Docker by following these steps:
1. Initiate the Gerrit using the command,
docker run -d-p 8080:8080.-p 29418:29418 openfrontier/gerrit
2. In the web browser, use the url, http://<docker host url>:8080
Advantages of Gerrit: The following are the advantages of Gerrit
✓ 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.
✓ 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.

17
 ✓ 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.
✓ 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.
✓ 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.
✓ Transparency: Gerrit provides a clear history of code changes, showing who made what changes
and why, which is valuable for tracking the evolution of the codebase.
Disadvantages of Gerrit:
• Reviewing, verifying and resubmitting the code commits slows down the time to market.
• Gerrit can work only with Git.
• Gerrit is slow and it's not possible to change the sort order in which changes are listed.
• You need administrator rights to add repository on Gerrit.
History Revisionism:
When we work with code together with other people in a team, the code’s history becomes more
important. This is especially important when work in with code review and code review tools such as
gerrit.
In terms of version control and software development, "history revisionism" refers to the process of
modifying or cleaning the commit history in a Git repository. This process can be particularly useful in
maintaining a clean and understandable project history.
In Git, changes made are recorded as a "commit," which forms a part of the project history. Sometimes,
the history can become messy due to multiple commits, unfinished work or mistakes. History revisionism
allows rewriting or tidying up of history before it becomes a permanent part of the repository.
1. Value of History Revisionism:
✓ Cleaner Project History: A clean commit history simplifies the process of reviewing the project
to understand the progression of changes. It helps maintainers and new contributors to analyze
the reasons of making certain changes.
✓ Eliminating Mistakes: If something is done accidentally or mistakenly, history revisionism
allows to fix such errors before they are shared with others.
✓ Squashing-Commits: Sometimes, multiple small commits are to be combined to form a single,
meaningful one. This process is called "squashing" which is a part of history revisionism.
2. Risks and Considerations: Irrespective of the usefulness of history revisionism, it should be used
carefully. When the commits are shared with others (pushed to a remote repository), rewriting history
can cause confusion or conflicts. Therefore, it is better to perform history revisionism before pushing
changes to the shared repository.
3. Tools in Git: Git provides various tools like git rebase, git commit --amend, and git reset for rewriting
history. These tools allow developers to reorder, edit, or squash commits to improve the clarity and
quality of the commit history.
In summary, history revisionism in Git is a powerful tool for maintaining a clean and understandable
commit history, but it should be used carefully to avoid potential issues when collaborating with others.

18
3.10 THE PULL REQUEST MODEL
The pull request model is an approach used in software development for managing and integrating
changes made by different developers. It is commonly used in version control systems like Git. The git
pull command is used to fetch and download content from a remote repository and immediately update
the local repository to match that content.
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.
This request enquires about the branch to be reviewed and merged into the main branch. 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 GitHub. The benefits of this model are as follows,
• Centralized Code Review: The pull request initiates a discussion among team members,
allowing for code review and feedback. This process helps in maintaining code quality.
• Flexibility: It allows teams to work in a more decentralized manner while ensuring that all
integrations are thoroughly reviewed.
• Asynchronous Review: Unlike traditional code inspections that require in-person meetings, pull
requests can 'be reviewed and discussed asynchronously, making the process more flexible and
efficient.
3.11 GITLAB
GitLab is a web-based Git repository manager that provides continuous integration, continuous
deployment, and other DevOps services. It is an open source code repository and collaborative software
development platform for large DevOps and DevSecOps projects. GitLab is free for individuals. GitLab
offers a location for online code storage and capabilities for issue tracking and CI/CD.
GitLab is a comprehensive platform for managing Git repositories. It offers several features that are
beneficial for development teams. It offers tools like wikis, issue tracking, and CI/CD (Continuous
Integration/Continuous Deployment) integration. This makes it a robust tool for managing the entire
development lifecycle. The key features are as follows
• CI/CD Integration: GitLab has built-in support for continuous integration and deployment,
which allows teams to automate testing and deployment processes. This helps in speeding up the
development cycle and ensures improved quality.
• Container Registry: GitLab offers a built-in container registry, which is especially useful for
managing Docker images. This feature simplifies the deployment of containerized applications.
• Hosting Options: GitLab can be hosted either on GitLab's servers or on own infrastructure,
providing flexibility depending on requirements of the organization.
While GitHub is popular and has a larger community, GitLab is preferred by many organizations due to
its robust CI/CD capabilities and more comprehensive feature set for DevOps practices.
19
GitLab supports many convenient features on top of Git. It's a large and complex software system based
on Ruby. As such, it can be difficult to install, what with getting all the dependencies right and so on.
There is a nice Docker Compose file for GitLab available at
https://registry.hub.docker.com/u/sameersbn/gitlab/.
If you followed the instructions for Docker shown previously, including the installation of docker-
compose, it's now pretty simple to start a local GitLab instance:
o Mkdirgitlab
o cd gitlab
o wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
o docker-compose up
The docker-compose command will read the .yml file and start all the required services in a default
demonstration configuration.
The GitLab container includes the Ruby base web application and Git backend functionality. Redis is
distributed key-value store, and PostgreSQL is a relational database. If you are used to setting up
complicated server functionality, you will appreciate that we have saved a great deal of time with docker-
compose. 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. They have been replicated here, but beware that they might change as the Docker image
author sees fit: Username: root and Password: 5iveL!fe
Features:
• GitLab hosts your (private) software projects for free.
• GitLab is a platform for managing Git repositories.
• GitLab offers free public and private repositories, issue-tracking and wikis.
• GitLab is a user friendly web interface layer on top of Git, which increases the speed of working
with Git.
• GitLab provides its own Continuous Integration (CI) system for managing the projects and
provides user interface along with other features of GitLab.
Advantages:
✓ GitLab provides GitLab Community Edition version for users to locate, on which servers their
code is present.
✓ GitLab provides unlimited number of private and public repositories for free.
✓ The Snippet section can share small amount of code from a project, instead of sharing whole
project.
Disadvantages:
✓ While pushing and pulling repositories, it is not as fast as GitHub.
✓ GitLab interface will take time while switching from one to another page.

20