Docker intermission

Docker is an open-source project with a friendly-whale logo that facilitates the deployment of
applications in software containers. It is a set of PaaS products that deliver containers (software
packages) using OS-level virtualization. It embodies resource isolation features of the Linux kernel
but offers a friendly API.

In simple words, Docker is a tool or platform design to simplify the process of creating, deploying,
and packaging and shipping out applications along with its parts such as libraries and other
dependencies. Its primary purpose is to automate the application deployment process and
operating-system-level virtualization on Linux. It allows multiple containers to run on the same
hardware and provides high productivity, along with maintaining isolated applications and
facilitating seamless configuration.

Docker benefits include:

● High ROI and cost savings
● Productivity and standardization
● Maintenance and compatibility
● Rapid deployment
● Faster configurations
● Seamless portability
● Continuous testing and deployment
● Isolation, segregation, and security

Docker vs. Virtual Machines

Virtual Machine is an application environment that imitates dedicated hardware by providing an
emulation of the computer system. Docker and Vmboth have their set of benefits and uses, but
when it comes to running applications in multiple environments, both can be utilized. So which
one wins? Let's get into a quick Docker vs. VM comparison.

OS Support: VM requires a lot of memory when installed in an OS, whereas Docker containers
occupy less space.

Performance: Running several VMs can affect the performance, whereas, Docker containers are
stored in a single Docker engine; thus, they provide better performance.

Boot-up time: VMs have a longer booting time compared to Docker.

Efficiency: VMs have lower efficiency than Docker.

Scaling: VMs are difficult to scale up, whereas Docker is easy to scale up.
Space allocation: You cannot share data volumes with VMs, but you can share and reuse them
among various Docker containers.

Portability: With VMs, you can face compatibility issues while porting across different platforms;
Docker is easily portable.
Clearly, Docker is a hands-down winner.

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
to merge changes to Git repository when you are done with the code reviews.
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.
Features of Gerrit
● Gerrit is a free and an open source Git version control system.
● The user interface of Gerrit is formed on Google Web Toolkit.
● It is a lightweight framework for reviewing every commit.
● Gerrit acts as a repository, which allows pushing the code and creates the review for your
commit.
Advantages of Gerrit
● Gerrit provides access control for Git repositories and web frontend for code review.
● You can push the code without using additional command line tools.
● Gerrit can allow or decline the permission on the repository level and down to the branch
level.
● Gerrit is supported by Eclipse.
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.
It is used to store the merged code base and the changes under review that have not being merged
yet. Gerrit has the limitation of a single repository per project.

Gerrit is first and foremost an arranging region where changes can be looked at prior to turning
into a piece of the code base. It is likewise an empowering agent for this survey cycle, catching
notes and remarks about the progressions to empower conversation of the change. This is
especially valuable with conveyed groups where this discussion can’t occur eye to eye.

How Gerrit Works Architecture?

Use case of Gerrit

● Knowledge exchange:
 The code review process allows newcomers to see the code of other more experienced
developers.
 Developers can get feedback on their suggested changes.
 Experienced developers can help to evaluate the impact on the whole code.
 Shared code ownership: by reviewing code of other developers the whole team gets a solid
knowledge of the complete code base.
The pull request model

Pull request is a feature of Git-based version control systems that allows developers to propose
changes to a Git repository and request feedback or approval f rom other team members. It is
widely used in DevOps to facilitate collaboration and code review in the software development
process.
In the pull request model, a developer creates a new branch in a Git repository, makes changes to
the code, and then opens a pull request to merge the changes into the main branch. Other team
members can then review the changes, provide feedback, and approve or reject the request.

Pull Requests are a mechanism popularized by github, used to help facilitate merging of work,
particularly in the context of open-source projects. A contributor works on their contribution in a
fork (clone) of the central repository. Once their contribution is finished they create a pull request
to notify the owner of the central repository that their work is ready to be merged into the mainline.
Tooling supports and encourages code review of the contribution before accepting the request. Pull
requests have become widely used in software development, but critics are concerned by the
addition of integration friction which can prevent continuous integration.

Pull requests essentially provide convenient tooling for a development workflow that existed in
many open-source projects, particularly those using a distributed source-control system (such as
git). This workflow begins with a contributor creating a new logical branch, either by starting a
new branch in the central repository, cloning into a personal repository, or both. The contributor
then works on that branch, typically in the style of a Feature Branch, pulling any updates from
Mainline into their branch. When they are done they communicate with the maintainer of the
central repository indicating that they are done, together with a reference to their commits. This
reference could be the URL of a branch that needs to be integrated, or a set of patches in an email.

Once the maintainer gets the message, she can then examine the commits to decide if they are
ready to go into mainline. If not, she can then suggest changes to the contributor, who then has
opportunity to adjust their submission. Once all is ok, the maintainer can then merge, either with
a regular merge/rebase or applying the patches from the final email.

Github's pull request mechanism makes this flow much easier. It keeps track of the clones through
its fork mechanism, and automatically creates a message thread to discuss the pull request, together
with behavior to handle the various steps in the review workflow. These conveniences were a
major part of what made github successful and led to "pull request" becoming a fundamental part
of the developer's lexicon.

So that's how pull requests work, but should we use them, and if so how? To answer that question,
I like to step back from the mechanism and think about how it works in the context of a source
code management workflow. To help me think about that, I wrote down a series of patterns for
managing source code branching. I find understanding these (specifically the Base and Integration
patterns) clarifies the role of pull requests.
In terms of these patterns, pull requests are a mechanism designed to implement a combination of
Feature Branching and Pre-Integration Reviews. Thus to assess the usefulness of pull requests we
first need to consider how applicable those patterns are to our situation. Like most patterns, they
are sometimes valuable, and sometimes a pain in the neck - we have to examine them based on
our specific context. Feature Branching is a good way of packaging together a logical contribution
so that it can be assessed, accepted, or deferred as a single unit. This makes a lot of sense when
contributors are not trusted to commit directly to mainline. But Feature Branching comes at a cost,
which is that it usually limits the frequency of integration, leading to complicated merges and
deterring refactoring. Pre-Integration Reviews provide a clear place to do code review at the cost
of a significant increase in integration friction. [1]

That's a drastic summary of the situation (I need a lot more words to explain this further in the
feature branching article), but it boils down to the fact that the value of these patterns, and thus the
value of pull requests, rest mostly on the social structure of the team. Some teams work better with
pull requests, some teams would find pull requests a severe drag on the effectiveness. I suspect
that since pull requests are so popular, a lot of teams are using them by default when they would
do better without them.

While pull requests are built for Feature Branches, teams can use them within a Continuous
Integration environment. To do this they need to ensure that pull requests are small enough, and
the team responsive enough, to follow the CI rule of thumb that everybody does Mainline
Integration at least daily. (And I should remind everyone that Mainline Integration is more than
just merging the current mainline into the feature branch). Using the ship/show/ask classification
can be an effective way to integrate pull requests into a more CI-friendly workflow.
The wide usage of pull requests has encouraged a wider use of code review, since pull requests
provide a clear point for Pre-Integration Review, together with tooling that encourages it. Code
review is a Good Thing, but we must remember that a pull request isn't the only mechanism we
can use for it. Many teams find great value in the continuous review afforded by Pair Programming.
To avoid reducing integration frquency we can carry out post-integration code review in several
ways. A formal process can record a review for each commit, or a tech lead can examine risky
commits every couple of days. Perhaps the most powerful form of code review is one that's
frequently ignored. A team that takes the attitude that the codebase is a fluid system, one that can
be steadily refined with repeated iteration carries out Refinement Code Review every time a
developer looks at existing code. I often hear people say that pull requests are necessary because
without them you can't do code reviews - that's rubbish. Pre-integration code review is just one
way to do code reviews, and for many teams it isn't the best choice.

The pull request model provides several benefits in DevOps:

Improved code quality: Pull requests encourage collaboration and code review, helping to catch
potential bugs and issues before they make it into the main codebase.
Increased transparency: Pull requests provide a clear audit trail of all changes made to the code,
making it easier to understand how code has evolved over time.
Better collaboration: Pull requests allow developers to share their work and get feedback from
others, improving collaboration and communication within the development team.
Overall, the pull request model is an important tool in the DevOps toolkit, helping to improve the
quality, transparency, and collaboration of software development processes.

GitLab
GitLab is an open-source Git repository management platform that provides a wide range of
features for software development teams. It is commonly used in DevOps for version control, issue
tracking, code review, and continuous integration/continuous deployment (CI/CD) pipelines.
GitLab provides a centralized platform for teams to manage their Git repositories, track changes
to source code, and collaborate on code development. It offers a range of tools to support code
review and collaboration, including pull requests, code comments, and merge request approvals.
In addition, GitLab provides a CI/CD pipeline tool that allows teams to automate the process of
building, testing, and deploying code. This helps to streamline the development process and reduce
the risk of introducing bugs or other issues into the codebase.
Overall, GitLab is a comprehensive Git repository management platform that provides a wide
range of tools and features for software development teams. By using GitLab, DevOps teams can
improve the efficiency, transparency, and collaboration of their software development processes.

What is Git?

Git is a distributed version control system, which means that a local clone of the project is a
complete version control repository. These fully functional local repositories make it easy to work
offline or remotely. Developers commit their work locally, and then sync their copy of the
repository with the copy on the server. This paradigm differs from centralized version control
where clients must synchronize code with a server before creating new versions of code.

Git's flexibility and popularity make it a great choice for any team. Many developers and college
graduates already know how to use Git. Git's user community has created resources to train
developers and Git's popularity make it easy to get help when needed. Nearly every development
environment has Git support and Git command line tools implemented on every major operating
system.

Git basics
Every time work is saved, Git creates a commit. A commit is a snapshot of all files at a point in
time. If a file hasn't changed from one commit to the next, Git uses the previously stored file. This
design differs from other systems that store an initial version of a file and keep a record of deltas
over time.

Commits create links to other commits, forming a graph of the development history. It's possible
to revert code to a previous commit, inspect how files changed from one commit to the next, and
review information such as where and when changes were made. Commits are identified in Git by
a unique cryptographic hash of the contents of the commit. Because everything is hashed, it's
impossible to make changes, lose information, or corrupt files without Git detecting it.

Branches

Each developer saves changes to their own local code repository. As a result, there can be many
different changes based off the same commit. Git provides tools for isolating changes and later
merging them back together. Branches, which are lightweight pointers to work in progress, manage
this separation. Once work created in a branch is finished, it can be merged back into the team's
main (or trunk) branch.
Files and commits

Files in Git are in one of three states: modified, staged, or committed. When a file is first modified,
the changes exist only in the working directory. They aren't yet part of a commit or the
development history. The developer must stage the changed files to be included in the commit.
The staging area contains all changes to include in the next commit. Once the developer is happy
with the staged files, the files are packaged as a commit with a message describing what changed.
This commit becomes part of the development history.

Staging lets developers pick which file changes to save in a commit in order to break down large
changes into a series of smaller commits. By reducing the scope of commits, it's easier to review
the commit history to find specific file changes.

Benefits of Git

The benefits of Git are many.

Simultaneous development

Everyone has their own local copy of code and can work simultaneously on their own branches.
Git works offline since almost every operation is local.

Faster releases

Branches allow for flexible and simultaneous development. The main branch contains stable, high-
quality code from which you release. Feature branches contain work in progress, which are merged
into the main branch upon completion. By separating the release branch from development in
progress, it's easier to manage stable code and ship updates more quickly.

Built-in integration

Due to its popularity, Git integrates into most tools and products. Every major IDE has built-in Git
support, and many tools support continuous integration, continuous deployment, automated testing,
work item tracking, metrics, and reporting feature integration with Git. This integration simplifies
the day-to-day workflow.

trong community support

Git is open-source and has become the de facto standard for version control. There is no shortage
of tools and resources available for teams to leverage. The volume of community support for Git
compared to other version control systems makes it easy to get help when needed.

Git works with any team

Using Git with a source code management tool increases a team's productivity by encouraging
collaboration, enforcing policies, automating processes, and improving visibility and traceability
of work. The team can settle on individual tools for version control, work item tracking, and
continuous integration and deployment. Or, they can choose a solution like GitHub or Azure
DevOps that supports all of these tasks in one place.

Pull requests

Use pull requests to discuss code changes with the team before merging them into the main branch.
The discussions in pull requests are invaluable to ensuring code quality and increase knowledge
across your team. Platforms like GitHub and Azure DevOps offer a rich pull request experience
where developers can browse file changes, leave comments, inspect commits, view builds, and
vote to approve the code.

Branch policies

Teams can configure GitHub and Azure DevOps to enforce consistent workflows and process
across the team. They can set up branch policies to ensure that pull requests meet requirements
before completion. Branch policies protect important branches by preventing direct pushes,
requiring reviewers, and ensuring clean builds.