Explore topic-wise InterviewSolutions in .

There are three means of setting up a script on the destination repository to get executed depending on when the script has to be triggered exactly. These means are called HOOKS and they are of three types:

• Pre-receive hook: This hook is invoked before the references are updated when commits are being pushed. This hook is useful in ensuring the scripts related to ENFORCING development policies are run.
• Update hook: This hook triggers the script to run before any updates are actually MADE. This hook is called once for every commit which has been pushed to the repository.
• Post-receive hook: This hook helps trigger the script after the updates or changes have been accepted by the destination repository. This hook is ideal for configuring deployment scripts, any continuous integration-based scripts or email notifications process to the team, etc.

DevOps is a culture-shifting practice that has and is continuing to help lots of businesses and organizations in a tremendous manner. It helps in BRIDGING the gap between the conflict of goals and PRIORITIES of the developers (constant need for change) and the operations (constant resistance to change) team by creating a smooth path for Continuous Development and Continuous Integration. Being a DevOps engineer has huge benefits due to the ever-increasing demand for DevOps practice.

Additional Resources

• Practice Coding
• DevOps Tools
• DevOps Engineer Salary

Sanity testing, also known as smoke testing, is a process used to determine if it’s reasonable to proceed to test.
Git REPOSITORY provides a hook called pre-commit which gets triggered RIGHT before a commit happens. A simple script by making use of this hook can be written to achieve the smoke test.

The script can be used to run other tools like linters and PERFORM sanity checks on the changes that would be committed into the repository.

The following snippet is an example of one such script:

The above script checks if any .py files which are to be committed are properly formatted by making use of the python FORMATTING tool pyfmt. If the files are not properly formatted, then the script prevents the changes to be committed to the repository by exiting with status 1.
 

It is also referred to as cache stampede which can occur when huge parallel COMPUTING systems employing caching strategies are subjected to very high load. It is referred to as that event that occurs when the cache expires (or invalidated) and multiple requests are hit to the website at the same time. The most common way of PREVENTING dogpiling is by implementing SEMAPHORE locks in the cache. When the cache expires in this system, the first process to acquire the lock WOULD generate the NEW value to the cache.

A blue-green pattern is a TYPE of continuous deployment, application release pattern which focuses on gradually transferring the user traffic from a previously working VERSION of the software or service to an almost identical new release - both VERSIONS running on production.

The blue environment would indicate the OLD version of the application whereas the green environment would be the new version.

The production traffic would be moved gradually from blue to green environment and once it is fully transferred, the blue environment is kept on hold just in case of rollback necessity.

In this pattern, the team has to ensure two identical prod environments but only one of them would be LIVE at a given point of time. Since the blue environment is more steady, the LIVE one is USUALLY the blue environment.

PAIR programming is an engineering practice where TWO PROGRAMMERS work on the same system, same design, and same code. They follow the rules of “Extreme Programming”. Here, one programmer is termed as “driver” while the other ACTS as “observer” which CONTINUOUSLY monitors the project progress to identify any further problems.

As the name indicates, IaC mainly relies on perceiving infrastructure in the same way as any code which is why it is commonly referred to as “programmable infrastructure”. It simply provides means to define and MANAGE the IT infrastructure by using configuration files.

This concept came into prominence because of the LIMITATIONS associated with the traditional way of managing the infrastructure. Traditionally, the infrastructure was managed manually and the dedicated people had to set up the servers physically. Only after this step was done, the application would have been deployed. Manual configuration and SETUP were constantly prone to human errors and inconsistencies.

This also involved increased cost in hiring and managing multiple people ranging from network engineers to hardware technicians to manage the infrastructural tasks. The major problem with the traditional approach was decreased scalability and application availability which impacted the speed of request processing. Manual configurations were also time-consuming and in CASE the application had a sudden spike in user usage, the administrators would desperately work on keeping the system available for a large load. This would impact the application availability.

IaC SOLVED all the above problems. IaC can be implemented in 2 approaches:

• Imperative approach: This approach “gives orders” and defines a sequence of instructions that can help the system in reaching the final output.
• Declarative approach: This approach “declares” the desired outcome first based on which the infrastructure is built to reach the final result.

Jenkins follows the master-slave architecture. The master pulls the latest CODE from the GitHub repository whenever there is a commitment made to the code. The master REQUESTS slaves to perform operations like build, test and run and produce test case REPORTS. This workload is distributed to all the slaves in a uniform manner.

Jenkins also uses multiple slaves because there might be CHANCES that require different test case suites to be run for different ENVIRONMENTS once the code commits are done.

Sudo STANDS for ‘SUPERUSER do’ where the superuser is the root user of Linux. It is a program for Linux/Unix-based systems that gives PROVISION to allow the users with superuser roles to use certain system commands at their root level.

Post Mortem meetings are those that are arranged to discuss if CERTAIN things go wrong while IMPLEMENTING the DevOps METHODOLOGY. When this meeting is conducted, it is expected that the TEAM has to arrive at steps that need to be TAKEN in order to avoid the failure(s) in the future.

In order to understand what this means, we FIRST need to know how the traditional SDLC cycle works. In the traditional cycle, there are 2 main sides -

• The left side of the cycle consists of the planning, design, and development phase
• The right side of the cycle includes stress testing, production staging, and user acceptance.

In DevOps, shifting left simply means taking up as many tasks that usually take place at the end of the application development process as possible into the earlier stages of application development. From the below graph, we can see that if the shift left operations are followed, the chances of errors faced during the later stages of application development would greatly reduce as it would have been identified and solved in the earlier stages itself.

The most popular ways of accomplishing shift left in DevOps is to:

• Work side by side with the development team while creating the deployment and test case automation. This is the first and the obvious step in achieving shift left. This is done because of the well-known fact that the failures that get notices in the production environment are not seen earlier quite often. These failures can be linked directly to:
  • Different deployment procedures used by the development team while developing their features.
  • Production deployment procedures sometimes tend to be way different than the development procedure. There can be differences in tooling and sometimes the process might also be manual.
• Both the dev team and the operations teams are expected to take ownership to develop and maintain standard procedures for deployment by making use of the cloud and the pattern CAPABILITIES. This AIDS in giving the confidence that the production deployments would be successful.
• Usage of pattern capabilities to avoid configurational level inconsistencies in the different ENVIRONMENTS being used. This would require the dev team and the operation team to come together and work in developing a standard process that guides developers to test their application in the development environment in the same way as they test in the production environment.