Home » Basics Of DevOps Explained

Basics Of DevOps Explained

by Dataflickr
0 comment

In this article, we will be learning about why do we need DevOps and how DevOps works if you enjoy our article in any tech company in any tech team you have two teams which are which basically contribute to a release of software the first team is called the development team and the second team is called the operations team.

What is the development team and what is the operations team a developer is basically a person who develops a code right he would develop the code and the code would then be forwarded to the operations guy whose job is to basically test the code and put it on the testing server.

The production server based on the requirement right now what was the problem here the problem was when the developer developed the code and he forwarded it to the operations guide the operations guys system could not run the code which the developer has forwarded,

Obviously, the developer would have tested the code that he is sending on his system first and only then he’s sending right on a successful operation on his system he will only forward the code to somebody else who wants to test it right but it did not run on the operating system it could be the problem of environment it could be the problem that he has not installed everything.

 which is required by the software so you used to push it back to the developer saying you know your code is not running on my system please check your code it is faulty right but now the developer was furious you know it ran fine on his system and if that operation is not installing something properly it’s not his problem right it’s not his job to go ahead and fix his system and then run the code because his job is to run,

develop the code which he is doing and the code is running fine on his system right so it’s the operations guy problem that he’s not able to run it on his system right so these were some of the problems that were between the developers and the operations guy and this was solved later but before that there was a lot of problem in team communication and it solved and it caused a lot of inefficiency in the team.

 The lean methodology we were talking about faster release cycles eliminating waste but this was a waste that we were not able to eliminate using lean methodology right and this was solved using DevOps right now the DevOps is what is DevOps exactly it is not a tool it is not a software suite it’s basically an idea is basically thinking  is obviously implemented using some tools,

DevOps it like I said it’s just an idea of working in a certain way that could solve the problem that we were facing between the development and the operations team so if you were to draw some differences between what we were doing earlier when we were working without DevOps ,

When we use DevOps is that the traditional IIT system was less productive although it was very productive as we saw in the lean methodology where we have eliminated everything we have tried everything in our hands to uh solve it using the planning part there was still some room of inefficiency that we could not solve using planning and that was solved using DevOps so DevOps was more productive than traditional.

In traditional IIT we had a skill-centric team right each team was skilled uh was killed in a particular territory and we had a lot of teams in our organization that used to work on different things now in DevOps what we do is the smaller teams are also specialized in different dopamines based on the silos right based on the technology,

Rather than having four people who are equipped or was skill centric in one particular technology in DevOps we had each person who was skill-setting in technology right so probably one person would know Cubans the other person would know DevOps better the other person would know to get better the other person could know some other technology better so we had celos like this right in traditional I t we used to invest more time in planning so when I talk about traditionality I’m talking about waterfall agile lean both collectively right so there was still some planning involved when we talk about traditional it.

In DevOps, we are saying we do smaller and frequent release cycles we do smaller and frequent release cycles as we saw by the end of linea lean and agile methodology that we are doing smaller release cycles DevOps take the advantage of those uh methodologies and implements it in its model as well that we have smaller and frequent releases but they’re still smaller than what we were seeing in lean and agile methodologies how is it we are going to discuss it in the future so DevOps still shortens the release cycle by the help of automation it’s a release cycle and hence releases software in even lesser days than or lesser weeks than we had in traditional id.

 If we talk about DevOps I would like to give you a fact that using DevOps methodology you can have release cycles in a day rather than weeks or months so every day there could be a release if you’re using DevOps methodology to the fullest.

This was again a good thing in traditionality when we were using the waterfall model, for example, it was difficult to achieve a targeted goal because the goal was set one year later right,

There was a difficulty in doing that reason being we could not foresee future right there could be some more problems that could be there while we are working on a project but everything cannot be planned in advance but in DevOps, because we are doing shorter release cycles it is not that difficult to achieve a target or goal it is easier to set objectives for a day than to set objectives for any year what you’re going to do right and that is why DevOps makes it easy for us or your employees to achieve their goals or their targets.

 The difference between what we had in the past probably when we were using waterfall methodologies in the past and what is present what we can currently achieve using the DevOps methodology like I told you guys earlier DevOps is nothing but a methodology it is an idea, it is not a tool it is not software it’s an idea or methodology of solving the problems between developer and operations guys.

The methodology involves a life cycle which as you can see in the diagram that the first thing that you do is plan what you have to do right then you code your way in then you build the code building the code means if you have a java file for example you’ll have to create a jar file or an executable file out of that so that is called building.

 Building your code and then you will be testing your code so what executable you have built you’ll test that code for any faults in the functionalities and if there are no faults you’ll release the code to the op stream now there are two kinds of release guys there’s an internal release and there’s an external release.

 The internal release talks about releasing the software to a different team of the company and this is what exactly is happening then comes a release phase where the developer guys release the software to the operation guys for their work the operations guy will in turn deploy the software on to the target system it could be a testing server which basically will test or do automated tests on it or it could be you know the production server where everything has happened the testing has happened and you’re deploying it on the production server so once you have deployed it of course now becomes the operation phase can be done internally or it could be done by your customers.

 You’re operating the software or you release the software for internal employees to see whether you know the traffic when is it doing good when it holds when it’s getting traffic onto it is it doing good when normal people are doing arbitrary tasks on your software and then you are also continuously monitoring it to see if you know your task is or your application is functioning properly and if it is not functioning properly you’re creating a log of events,

Which are happening right which this is called monitoring and after monitoring again comes the planning phase it means if you get any kind of feedback from the monitoring part you again start planning it how to do it how to solve this kind of a problem that you’re getting in the monitoring phase and then code your way in build the code again test it releases it to the op sky and this goes on and on until you get a perfect application.

 There are no perfect application guys right always there will be new requirements coming in always there will be some bugs always there will be some security patches and therefore this life cycle goes on and on so this is what DevOps …

 If you want to think about it how is it solving the problem between the dev and the op skies is by automating this life cycle that means that now the developer does not have to give the code to the op sky it will be given through a tool which we have which so there is a tool called Docker!

The dev guy will enclose his code inside docker and will push it to the ops team and the option just have to run docker and this code will run fine right there is no problem for dependency there is no problem for configuration management everything happens automatically in this life cycle so don’t worry if you don’t understand exactly what DevOps is because in our next slides we’re going to discuss how it works right so going forward now let’s discuss how the DevOps life cycle works.

  If you were to that infinity sign that we had it if you were to condense it or if you want to expand it so that that develops life cycle diagram that we had the infinity diagram that we had if you were to expand it would look something like this right so you have something called as planning you have something called as coding building and testing now this used to happen on the developer’s side.

 We go on to the op side where we have release we have to deploy you have operated and then you have a monitor right so in between this we have to integrate this part of the developer’s side to this side of the operator side and this is done using continuous integration now what is continuous integration we’ll discuss in a while but for integrating the developer and the operations guys we use continuous integration.

What is continuous integration let’s pay attention to what we have over here as well right so the planning and coding phase we contribute or we collectively call it continuous development what is continuous development I’ll explain to you in a little while building and testing we call it continuous testing. releasing and deploying we call it continuous deployment operation and monitoring we call it continuous monitoring …

 Start with planning you do coding you build it you test it you then release it to the ops team then you deploy it then you operate it and then you monitor it and this gives rise to five stages that are continuous development continuous testing continuous integration continuous deployment continuous monitoring which again goes back to continuous development now let’s understand these terms let’s understand what is continuous development testing deployment monitoring and integration.

The life cycle guys now why are we calling it continuous means it goes on and on right it never stops so like I told you in the diagram for DevOps that the cycle goes on and on it never stops the product is always being developed right it is always in some part of the life cycle so if you were to explain continuous development and continuous integration continuous testing this is the best way to learn it.

We have a developer who basically will be pushing his code to a version control system and this version control system will any changes in this version control system will be taken up by a continuous integration tool what is a continuous integration tool does nothing but joins each of these stages to each,

For example, if I have to go from continuous development to continuous testing and if this happens in separate software continuous integration will join these and this right continuous integration will join testing and then deployment continuous integration will join monitoring and then again coming back to development and how does this happen it happens like this so there is a software which does continuous integration.

 Let’s understand just this as a black box this is a software that does continuous integration and the function for this particular software is the moment you push your code to a version control system this version control system is nothing but software that takes care of storing your code. that moment you push your code to a version control system,

You change your code in the version control system the continuous integration tool automatically identifies. there’s a change in the version control system just a quick info guys if you want to make a career in cloud and DevOps what it does is it takes this code and it builds it on the testing server it first builds it and tests it on the continuous on the testing server and this is called continuous testing.

 The reason being every developer who does this continuous integration does the job similarly right so if there are 100 developers in the team so for every developer if we configure a version control system that for every developer it has to test the code it’ll always do that. Every developer who’s doing a version controls who is pushing his code to version control system continuous integration software is going to test their code on the testing server right and this is the reason it’s called continuous because it happens continuously.

Continuous development we push our go-to version control system it is identified by the continuous integration tool so the first job that continuous integration tool does is it pushes on to the testing server the code where it is built and tested and if the test succeeds continuous integration tool pushes it on the production server.

Now either if it’s on the production server or if it’s on the testing server now if on the testing server there are some bugs which are identified the feedback is given through continuous monitoring to the developer or if the production server, if there are some problems on the production server or like I, said when you deploy your code on the production server it basically gets available to the world and it gets continuously monitored.

 Any kind of problems which are occurring gets continuously monitored and the logs are generated and these logs are being stored somewhere using continuous monitoring so your production server is continuously monitored for any kind of activity which is happening on it,

The logs are being generated now developers the team when I go back to the developer why am I coming back over here because this identifies or this tells us now that when the development team is done with the release and now they have to see what all what other work I have to do all they have to do is check the logs from the corner continuous monitoring tool right and they’ll be able to identify.

  This is causing a problem and also the users are saying that you know we should have this feature, uh the client came in he also wants some features,

They plan a release right and once the planner release they again start coding and again once they’re done with the code they’ll push the code to version control system which will be identified by the continuous integration tool which will then automatically test it once it’s been tested if it’s successful it’ll push to the production server again the logs will be identified by the continuous monitoring stage again it will go to the developer after planning and then he’ll code his way into the version control system and the life cycle.

 This is exactly how DevOps work right now let’s look at each of these stages independently to understand what exactly happens in continuous development what exactly happens in continuous integration.

continuous development you basically push your code to a version control system the version control system could be software like git or software like svn right now you when the movement you push your code to the version control system it basically creates a new version of your code,

For example, if you wrote an ABC on a text file right now that ABC you wrote and you upload it on the version control system so this was the first version the version control system automatically makes it version one the moment you make some changes and again push it to the version control system what happens it creates the version one was the text file having ABC now the new version that you have pushed it becomes version two and the file would be ABC and probably whatever changes you have made to the file.

 It creates a new version and at the same time it also holds on to the previous version so that in any case in any problems that you might have in the future if you want to revert to the previous version you can easily do that and that is why we have a version control systems like git and sbn and continuous development is an integral part of pushing code to your version control system.

  This is continuous development then you have continuous integration now what is continuous integration this is nothing but integrating your life cycles for example once you push the code to your version control system it has to be picked up and pushed onto the testing server for testing where it could be built and tested.

All these life cycles are integrated or there is someone who is doing the manual job of a person of putting taking code from one stage and put it pushing it on to another then taking the results from there pushing it on to another then taking the results from there pushing onto another and that manual effort is being done by a tool which is called the continuous integration tool…

Have continuous deployment means you will deploy your code onto a particular server it could be a testing server it could be a production server and deployment involves putting the right kind of software on it and then pushing the build onto your server so that it has the right software environment where it will function and again putting installing software on the system and everything is also automated using a tool which is used in the continuous development life cycle.

Continuous testing is a life cycle stage wherein you continuously test your software so like I told you guys in this what happens is you continuously build and then test your code so your code is pulled from the version control system it is built.

 When I say built it is converted to an executable file and this executable file is then run right now the continuous testing how it happens is you create auto testing suits that are pre-installed in the testing server and the moment it gets a new executable all those test suites are executed on this particular executable file to check if all the tests are passed or not right,

If all the tests are passed it is then again picked up by the continuous integration tool and then pushed on to the production server once it reaches the production server again it gets monitored, it gets monitored for the user any errors it gets monitored for any user comments on version upgrades right on version upgrades or you can say any feature requests so all those feature requests all those errors all those logs are then visualized or then are then stored inside a monitoring tool.

 This monitoring tool helps us in sorting these logs based on what we wanted it will sort it based on general logs is sorted based on error logs it will sort it based on feature requests right so it becomes a one destination stop for you where you can check and plan your day or plan your team’s work for the near future.

 This is continuous monitoring so these were all the life cycle stages of DevOps guys and these life cycle stages make it possible for us to have shorter release cycles because all these stages are automated and these are automated using tools and these tools we’ll be discussing in our next session where we’ll get an introduction to all the tools which come together to create a DevOps.

 We have discussed the DevOps methodology how the DevOps life cycle work but they are incomplete without their respective tools which will map to each of the life cycle stages in the DevOps life cycle.

 Let’s go ahead and start these tools uh with their respective stages so the first stage that we saw was continuous development now continuous development is implemented using version control systems as I told you and in most of the companies the most used version controls tool is git.

Git is a version control system which is which will be also used in this course and it is used when multiple people are working on one particular project it is great for team collaboration it is great for tracking changes and is awesome on the command line. this is what we are going to learn in this course so for git maps to the continuous development lifecycle stage then we have continuous integration now you heard a lot about this continuous integration tool event we were discussing in the DevOps lifecycle and the tool is called Jenkins.

 Jenkins is an open-source tool right which is used to implement the continuous integration features that we saw in the DevOps life cycle in this course we’ll be learning Jenkins and there is a separate module on Jenkins that will be devoted to explaining different features that you can explore in Jenkins.

 The next stage is continuous deployment and continuous deployment means two things it means configuration management, virtualization, and containerization so we use docker for virtualization and containerization, and what exactly docker does is so the problem of running your code on one system and not being able to run on another system is what uh is solved using containerization so what containerization does is it wraps your code along with the software dependencies and it all these software dependencies and code is wrapped around by a container.

 A container is a physical entity that will wrap your software dependencies and your software and it will if you run that container on any other system it will run as if you know it is running on the same system that is on the developer’s computer.

 A container is an executable form of an operating system that can be run on any system the only pre-requirement is that you should have docker installed on it right similarly you have configuration management now configuration management what is configuration management.

 You have a computer you have a freshly set up computer and on which you have some operating system installed now if you want to test your application on that system what you have to do is you first have to install all the software on it.

 For example like I said you would need docker for your container to run you probably would need an apache server you would need python or all these software that have to be installed can be installed using configuration management without even touching that remote computer or that freshly set up the computer and that is possible using tools like puppet and ansible more of which we will be seeing in our course as we progress in our number of modules.

 The next stage is continuous testing now continuous testing as we learned was all about creating testing suits that would automatically test your code once it gets built on your system, all these automation testing shoots can be created using the selenium software.

 We will be learning the selenium web driver in this course as we move along and we will see how we can create our automation shoots in selenium for testing our applications this was about continuous testing and then next we have continuous monitoring wherein you know that your application is continuously monitored and the logs have created any errors are also monitored, all of that is done using Nagios, Nagios gives you a dashboard with all your services listed on it and those services can exist on any system outside the network or inside the network and all these services running on it can be seen on the Nagios dashboard.

 It’s a great tool for monitoring your application and a great tool for gathering user data or user activity data at a one-stop destination that is what Nagios is all about and this brings us to all the tools, these were all the tools that we will be discussing throughout the course and this brings us to the DevOps tools life cycle.

 if you saw the DevOps life cycle earlier wherein you had a developer and the developer was pushing code onto the version control system this is a replica of that figure and in this figure, we have just replaced the tools with the life cycles.

 What the developer does is he pushes his code to GitHub the GitHub from GitHub Jenkins automatically detects that you know on Github your code has been changed it pulls the code and pushes it onto the testing server and it installs all the software required on the testing server and the testing suite that has been built on the selenium is already present on that testing server.

Jenkins pushes the code here the code is built and tested over here if it goes successful Jenkins again pushes the code to production and on the production server, Nagios continuously monitors it for user activity how many users are logged on what the users are saying about it all of that information is saved inside Nagios and that information can be seen on the Nagios dashboard by the development team and they can make a plan for the next release what all features they have to include what all fixes they have to do and once you do that you know again start on with your next release so this is what you do when you are working with the DevOps tools and this portrays the whole DevOps life cycle.

You may also like

© 2023 DataFlickr. ALL RIGHTS RECEIVED.