Answer:- CI or Continuous Integration is the process of compiling the entire code base, every time a member of the software development team checks the code, into the shared source code repository. If a team member checks into the code file with a bug, then the build gets broken. In this sort of scenario, other developers can’t synchronize the shared source code repository without introducing compilation errors into their own local workspaces. Thus, collaborative and shared software development cannot go forward. When a CI build breaks, it is crucial that the problem is corrected immediately. A CI process often includes a suite of unit, and integration and regression tests that run every time the compilation succeeds. If any of these tests fail, the build will be considered unstable, not broken.

Answer:- Three of the most common DevOps KPIs are: • Meantime to failure recovery • Deployment frequency • Percentage of failed deployments

Answer:- Continuous deployment is fully automated, and the deployment to production needs no manual intervention in continuous deployment; whereas, in continuous delivery, the deployment to production requires some manual intervention for change management in the organization, and it needs to be approved by the manager or higher authorities to be deployed in production. According to your organization’s application risk factor, continuous deployment/delivery approach will be chosen.

Answer:- DevOps can’t be referred to as a tool; it is a collaborative work culture that combines development and operations teams for continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring.

Answer:- The core operations of DevOps are application development, version control, unit testing, deployment with infrastructure, monitoring, configuration, and orchestration.

Answer:- According to the current market trend, instead of releasing big sets of features in an application, companies are launching small features for software with better product quality and quick feedback from customers, for high customer satisfaction. Now, to keep up with this, we have to: • Increase the deployment frequency in the safest and reliable way • Lower the failure rate of new releases • Shorten the bug resolution time DevOps fulfills all these requirements for fast and reliable development and deployment of software. Companies like Amazon and Google have adopted DevOps and are launching thousands of code deployments per day. But Agile, on the other hand, only focuses on the development of software.

Answer:- DevOps can be considered as complementary to the Agile methodology but not completely similar.

Answer:- Data redundancy and replication High availability Only one Git directory per repository Superior disk utilization and network performance Collaboration friendly Can be used for any sort of projects

Answer:- The command ‘git pull’ pulls any new commits from a branch from the central repository and then updates the target branch in the local repository. But, ‘git fetch’ is a slightly different form of ‘git pull’. Unlike ‘git pull’, it pulls all new commits from the desired branch and then stores them in a new branch in the local repository. In order to reflect these changes in your target branch, ‘git fetch’ must be followed with a ‘git merge’. The target branch will only be updated after merging with the fetched branch (where we performed ‘git fetch’). We can also interpret the whole thing with an equation like this: git pull = git fetch + git merge

Answer:- • It helps improve the collaborative work culture: Here, team members are allowed to work freely on any file at any time. The version control system allows us to merge all changes into a common version. • It keeps different versions of code files securely: All the previous versions and variants of code files are neatly packed up inside the version control system. • It understands what happened: Every time we save a new version of our project, the version control system asks us to provide a short description of what was changed. More than that it allows us to see what changes were made in the file’s content, as well as who has made those changes. • It keeps backup: A distributed version control system like Git allows all team members to have the complete history of the project file so that in case there is a breakdown in the central server, they can use any of their teammate’s local Git repository.

Answer:- In order to resolve the merge conflicts in Git, we need to follow three steps: • Understand what happened: It could be because of the same line edit on the same file; it could be because of deleting some files, or also it could be because of files with the same file names. You can check everything by using ‘git status’. • Mark and clean up the conflict: When we open the files using the merge tool, Git marks the conflicted area like this ‘<<<<< HEAD’ and ‘ >>>>> [other/branch/name]’. • Perform commit again and then merge the current branch with the master branch.

Answer:- Forking Workflow is fundamentally different from other Git workflows. Instead of using a single server-side repository to act as the ‘central’ codebase, Forking Workflow gives every developer their own server-side repositories. This workflow is most often seen in public open-source projects. The main advantage is that contributions can be integrated without the need for everyone to push to a single central repository to maintain clean project history. Developers can push to their own server-side repositories, and only the project maintainer will push to the official repository. As soon as developers are ready to publish their local commits, they will push their commits to their own public repositories. Then, they will perform a pull request from the main repository, which notifies the project maintainer that an update is ready to be integrated.

Answer:- Both ‘git rebase’ and ‘git merge’ commands are designed to integrate changes from one branch into another branch: just that they just do it in different ways. When we perform rebase of a feature branch onto the master branch, we move the base of the feature branch to the master branch’s ending point. By performing a merge, we take the contents of the feature branch and integrate them with the master branch. As a result, only the master branch is changed, but the feature branch history remains the same. Merging adds a new commit to your history. Rebasing will create inconsistent repositories. For individuals, rebasing makes a lot of sense. Now, in order to see the history completely, the same way as it has happened, we should use merge. Merge preserves history, whereas rebase rewrites it.

Answer:- Both ‘git rebase’ and ‘git merge’ commands are designed to integrate changes from one branch into another branch: just that they just do it in different ways. When we perform rebase of a feature branch onto the master branch, we move the base of the feature branch to the master branch’s ending point. By performing a merge, we take the contents of the feature branch and integrate them with the master branch. As a result, only the master branch is changed, but the feature branch history remains the same. Merging adds a new commit to your history. Rebasing will create inconsistent repositories. For individuals, rebasing makes a lot of sense. Now, in order to see the history completely, the same way as it has happened, we should use merge. Merge preserves history, whereas rebase rewrites it.