DevOps, using the youth lingo, is actually a ship name for “Development” and “Operations”. It mainly focuses on rapid and efficient delivery through automation and agile procedures in an organized and methodical manner. To give an outline of the concept in simpler terms, DevOps is basically a method in which organizations cooperate using cross-functional teams.
In this blog, we will be discussing all the what, why and how questions about DevOps.
Let’s begin with what gave rise to DevOps?
Software Development Life Cycle (SDLC) is a process used in the industry to design and develop high edge software. A few SDLC models are the Waterfall model and the Agile Model. Waterfall Model is fairly linear and sequential, one stage will come after the other and it only goes to the next stage when the previous stage is complete thus giving rise to the need of delivering complete information and requirements at the time of creation. As requirements change frequently, this model wasn’t much of a help. Even though this model produced results, it wasn’t as useful. For years there has been an inconsistency in the development lifecycle. The product often delivered for testing was not the same as the delivered product. The stages were prolonged and time-consuming. This was mostly caused due to human-based actions or errors. This gave birth to a need for an automated process.
The improved model was the Agile model. Now, what does Agile mean? It is how teams iterate, with short development cycles and fast feedback.
In this method, the whole product model is not made at once, it is broken into various subparts and is delivered at fixed intervals. The concept is based on iterations and thus it gave more flexibility to the developers and also importance to the customer feedback. Due to this, the customers were more satisfied, and the problems of the Waterfall model were cured. This gave rise to DevOps.
DevOps isn’t a Technology, as many perceive. It is rather a methodology. It creates a space for development engineers and operations engineers to participate and coexist in a software lifecycle. The main objective of DevOps is to bridge the gap between the deaf side and the offset side of the company. It is automated, simply put, if the product crashes at midnight, it can fix itself without creating a huge amount of losses for the company. Due to the benefits DevOps and provides, it is becoming a culture – more like a solution that many new edge companies are adopting.
Now that we have a clear idea about what DevOps aims to do, we need to now know how it achieves them. The whole procedure is not performed at once as one may think, it is actually broken into several steps.
What are the steps of DevOps?
This explanation becomes easy when you know what is version. Suppose you are developing a product. The 1st ever complete outcome is the first version of the product ( say version 0.1). Now you, being the creator can add (commit) new features to your product. The newly developed product becomes the next version (say version 0.2). In the same way, you can keep on adding or removing products creating multiple versions of it.
These changes that you make to the original code are saved in a repository.
For example, You have developed a mobile phone with 3 features( call, internet, messaging ). The 1st running model is known as “Version 1”. Now you want to add a feature (camera), to your 1st version. This new mobile phone with all the four features ( call, internet, messaging and camera) will be the next version of the product i.e. “Version 2”. If a customer wants to buy the phone without the camera feature, they can simply retrace to the previous version and if they want the new version, they can readily avail it.
The ability to organize and control the changes in the repository so that none of the codes overlap and maintain all the versions is known as Version Control. This gives rise to a huge benefit of DevOps. The developer can keep track of the changes and developments made to the versions and can “traceback” to any version they want. Ex: if a version is creating a bug problem then the developer can see which “commit” caused the problem, traceback and fix it.
Version Control is supported with the help of platforms like Git, JIRA, etc.
It is a development practice in which the developers are required to commit to changes to the source code in a shared repository several times. After that, the Jenkins server (a continuous integration server) will “pull” the change and will prepare a “build”.
What is Build? The build stage is not just the compilation of the code, it reviews the code, it performs until testing and integration testing.
After the build, the code is now formed to an executable product. It is called a “package” of JAR or WAR format. This package is directly sent to Continous Delivery.
It is phase 2 of continuous integration. In this stage, we take the “Built” application to the test server for end-user testing. That is, we “DEPLOY” the build application to the test server for UAT (User Application Test). Here the code changes are automatically prepared for production. At the end of this process, the developer will have a product that has passed all the standardized tests. These said tests are necessary before being sold to the customers. There are multiple parallel tests going on before deployment.
For example, suppose today you want to build a robot and sell it. You build the robot in the cool, closed environment of your office and you sell it to your friend. Your friend lives in a very sunny state and after a few months of usage, the machine fails to withstand the temperature. This creates a loss of both your efforts and your friend’s money. This situation could’ve been avoided if the robot was “tested” beforehand.
- If errors occur, we will know which commit had caused it, without going through the whole code
- If any bug appears, it can be treated accordingly.
Takes the application that you have just tested and deploys it on the prod server for its release in an automated fashion. In other words, “production occurs without explicit approval.“
This brings in the concept of the Dark Launching Technique.
It is a process in which the features are deployed to a small user base. This user base is continuously monitored and their feedback is taken and the features are made better by continuous deployment and testing. Once the features are stable, they are deployed to the rest of the users over multiple releases.
How does DevOps work in an organization?
Every organization that is employing DevOps has SRE. Now, what is SRE? It stands for System Reliability Engineer (sounds like a designation, it actually is!). It is how is engineering organizations automate, entrusting operations to people with a software engineering background.
The DevOps engineer is far more than someone who simply pushes a button to kick off an automated build because of some financial/security/audit requirements. Instead, they become part of the development lifecycle, with a focus on making sure the feature code is not only reaching the target destination but doing so with the right design in place. They also focus on automation and migrate away from anything driven by an individual’s action.
Example: we will have a look at how to employ the concepts of DevOps using BitBucket.
- LOG-IN / SIGN UP to your Bit Bucket account.
- Create a Repository.
HOW TO CREATE A REPOSITORY?
- CLICK on the (+) sign on the left-hand side of the screen.
- A dialog box will appear.
- Give an appropriate name and select the type of access you want.
- On clicking CREATE, you will get a Repository.
- Now you create a README file.
- Click COMMIT.
On clicking Commit you will get the MASTER BRANCH
- BRANCH and COMMIT are two categories in the menu that will show you the branches and commits that you have made. (insert pic)
- In the BRANCH option, you will get the Master Branch. We cannot directly commit changes to the master branch because we do not want to lose the original code and data. Hence we will create a Development Branch
How to create a Development branch?
- Click on CREATE BRANCH
- A new pop-up will appear
- Enter the appropriate branch name
- Click CREATE
An Exact copy of the Master Branch is put into the Development Branch.
How to create a Local Repository?
- The local repository is the repository present in your system and the remote repository is the one you just created in Bitbucket.
- Go to your command line
- Create a folder with the command MKDIR
- Go inside the folder with the command CD
- Now for ease of understanding, we will create a text file. We will push this text file into the remote repository that is on BitBucket.
How to initialize the local Repository as a Git Repository?
- There is a specific command for this purpose. Called GIT INIT
How to add a local repository to a remote repository?
- Click on the CLONE button on the right-hand side on the screen. A pop up will appear.
- Copy the URL
- We have a command called GIT REMOTE ADD ORIGIN followed by the URL. this connects the local repository to the bitbucket repository.
How to check status?
- To check the status of our local repository, we will use the command GIT STATUS
- It will give the name and number of files present in the local repository, which we need to push into the remote repository.
How to add files to the index before committing?
- Use command GIT ADD. it adds files to the index before coming.
- Commit command saves the changes to our local repository.
- The command is GIT COMMIT
How to push it into the remote repository?
- There is a command called GIT PUSH ORIGIN MASTER
This pushes the code into the remote repository. Thus the changes that were made are now pushed into the master branch and the working tree will be empty.
It is vital to understand the benefits and disadvantages of using DevOps before readily applying them directly to your organization.
Benefits of DevOps:
- Improvement in product quality
- Faster software releases (Faster deployment)
- Ability to solve critical issues quickly
- Better manage unplanned work
- Minimal cost/loss
- Improvement in the productivity of the organization
- DevOps isn’t only about automation. Even though it makes the going get easier but it still can have unintended consequences if it is not monitored and controlled.
- DevOps specialized engineers are hard to find as the concept is new to the market.
- Since the way about DevOps is automation, it often takes away the chance of careful consideration of certain decisions a developer might want to take.
To conclude, we can say that DevOps is more into an automated mechanism and it aims to resolve its problems as quickly as possible. An organization should not employ Devops because it seems logical( XD ), it organization must be ready for such a drastic culture change. If half hearted efforts are made then the results can be drastic and not beneficial as the automations tools and other supplies do cost alot of money.
At the core of every great company is great planning, not the unnecessary usage of available technology. So it is important for every organization to realise and understand their priorities and act according to them.
HAPPY CODING & HAPPY LEARNING EVERYONE!