Understanding basics of DevOps
Today in IT industry, a buzz word is DevOps. Many people are talking about this. Every organization tries to adopt the same.
But the questions pop up in my mind are:
In a typical Software development cycle, we do the following tasks:
What I understood from those steps are:
Let’s take an Example: Suppose a developer develops a feature and runs the unit tests. After a successful unit test, he/she commits the code to VCS. Then the same developer wants to test that code by going through QA according to test scripts. So he or she has to mail it or raise a ticket on a bug tracking system. The developer updates the status and assigns to the testers, but the tester is currently testing other features, so the developer has to wait for confirmation. Here the blocking state starts.
The developer then picks up another feature from his plate. After 2-3 days, the tester tests this implementation and returns to the developer, as there is a defect. So now, the developer is busy with new requirements so the bug is waiting for something to happen.
This is the typical scenario we work. If I want to search for the actual problem I found that this is due to the process and chaos that is created when there are too many functional teams involved and they are highly dependent on each other.
Another scenario you can consider: Suppose a bug was found in production. The developer inspects it and found that it is due to memory space issues, so to solve the problem we need to add a server into the server pool. Then developer contacts the IT-Operations team, who suggest raising a ticket and assigning it to Operations. Once it is approved by the Operations head, the Operations team adds the server into the pool. To solve a small problem we have to wait for 2-3 days to communicate with other functional teams.
Development, Operations, or Testing teams do not take an order without a ticket because their performance counts on that ticket. So, processes hinder us from smooth delivery.
Suppose you have a property file where you mention the path where you need to place your uploaded files, as the developer system is different from production. The developer set this path to local home, which is Windows home, but forgot to revert it when he/she commited the files.
In SIT environment, suddenly the tester discovers that upload functionality fails due to the wrong home directory.
Not only that, the developer's VDI m/c has been changed frequently for improving performance so in new VDI m/c he has to set up his whole project which takes just 1-2 days to set up dependency and run on the local server.
Due to these pain points, DevOps rises and tries to rescue us from this apocalypse.
DevOps is a culture which promotes Continuous Delivery. Or I can say it promote a delivery pipeline concept where everything, from a commit to a production release should be in a pipeline with full automation, no human intervention needed.
There is a subtle difference between Continuous Integration, Continuous Deployment, and Continuous Delivery. I will discuss them in an another article.
For now, we can consider DevOps to dissolve the problem of “cross-functional team involvement."
DevOps is like the conveyer belt, and consists of multiple tools that take care of all the steps I mentioned earlier. DevOps also takes care of orchestration and make sure that the developer's environment should be the same as production. By using Puppet or Chef it can be archived. Docker is another container management tool which works very well in the context of DevOps.
Agile methodology is an integral part of DevOps, so we can build a minimal viable product, show to a client, and take next steps based on client feedback. Don’t go for big target, break it down into small feasible targets to achieve it.
Now the last question: is DevOps a necessity or ornamental?
It is totally based on your product. If your product is simple and won’t change very frequently, the cost to implement DevOps will be high. On the other hand, if your product is complex and very costly I personally think you should go for DevOps.
But the questions pop up in my mind are:
- What is DevOps?
- Why should I use this?
- What are the problems with legacy software management?
- Is DevOps necessity or ornamental?
In a typical Software development cycle, we do the following tasks:
- Gather requirements from client.
- Doing some HLD, LLD, blah, blah, blah.
- Set up a Version Control System (VCS) to maintain the code base.
- The developer implements code on their local machine.
- Run unit tests on that implementation.
- Commit the code into the Version Control System.
- Developer sends a ticket to the infrastructure team to build and deploy the code in a QA environment.
- Infrastructure team deploys the code into the test environment.
- QA tests the code according to test cases and scripts.
- Then QA raises a ticket to the infrastructure team to deploy the code in an SIT environment.
- Infrastructure team deploys the code into SIT environment.
- QA does the integration testing.
- If all the previous steps are successful, we are ready to deploy to production.
- We set up a meeting with the client and set a fixed date for deployment.
- The infrastructure team gets ready to deploy the product to production.
- The infrastructure team completes the deployment and sends a status report to the team about the deployment.
- In production, if any post-production bugs are reported, we follow the same steps again.
What I understood from those steps are:
- Many cross-functional teams are involved in the cycle.
- Developers need an environment to work seamlessly in.
- As per the previous project model (waterfall), a product will be delivered to production a long time after requirements are gathered.
Communication
As I said earlier there are many cross-functional teams involved in the cycle, so hand shaking between them is inevitable. This is the potential point where project progression is blocked.Let’s take an Example: Suppose a developer develops a feature and runs the unit tests. After a successful unit test, he/she commits the code to VCS. Then the same developer wants to test that code by going through QA according to test scripts. So he or she has to mail it or raise a ticket on a bug tracking system. The developer updates the status and assigns to the testers, but the tester is currently testing other features, so the developer has to wait for confirmation. Here the blocking state starts.
Blocking State
The developer then picks up another feature from his plate. After 2-3 days, the tester tests this implementation and returns to the developer, as there is a defect. So now, the developer is busy with new requirements so the bug is waiting for something to happen.
This is the typical scenario we work. If I want to search for the actual problem I found that this is due to the process and chaos that is created when there are too many functional teams involved and they are highly dependent on each other.
Another scenario you can consider: Suppose a bug was found in production. The developer inspects it and found that it is due to memory space issues, so to solve the problem we need to add a server into the server pool. Then developer contacts the IT-Operations team, who suggest raising a ticket and assigning it to Operations. Once it is approved by the Operations head, the Operations team adds the server into the pool. To solve a small problem we have to wait for 2-3 days to communicate with other functional teams.
Development, Operations, or Testing teams do not take an order without a ticket because their performance counts on that ticket. So, processes hinder us from smooth delivery.
Infrastructure
Infrastructure is another pain point. In a typical project, I have seen developers working in VDI. Not only that, the biggest problem is that developers work on Windows, but the production or SIT environments run on Linux. So the developer's machine is not a replica of the production server. When a developer is not confident about their code, silly things can happen.Suppose you have a property file where you mention the path where you need to place your uploaded files, as the developer system is different from production. The developer set this path to local home, which is Windows home, but forgot to revert it when he/she commited the files.
In SIT environment, suddenly the tester discovers that upload functionality fails due to the wrong home directory.
Not only that, the developer's VDI m/c has been changed frequently for improving performance so in new VDI m/c he has to set up his whole project which takes just 1-2 days to set up dependency and run on the local server.
Production Release
Another problem is a waterfall approach takes a long time to release a project /product to the clients. So it can happen when you think about the project functionality that is a unique idea but delays to release the product, another competitor thinks and releases the idea before you. So you are in a losing spiral just to maintain the process.Due to these pain points, DevOps rises and tries to rescue us from this apocalypse.
DevOps is a culture which promotes Continuous Delivery. Or I can say it promote a delivery pipeline concept where everything, from a commit to a production release should be in a pipeline with full automation, no human intervention needed.
There is a subtle difference between Continuous Integration, Continuous Deployment, and Continuous Delivery. I will discuss them in an another article.
For now, we can consider DevOps to dissolve the problem of “cross-functional team involvement."
DevOps is like the conveyer belt, and consists of multiple tools that take care of all the steps I mentioned earlier. DevOps also takes care of orchestration and make sure that the developer's environment should be the same as production. By using Puppet or Chef it can be archived. Docker is another container management tool which works very well in the context of DevOps.
Agile methodology is an integral part of DevOps, so we can build a minimal viable product, show to a client, and take next steps based on client feedback. Don’t go for big target, break it down into small feasible targets to achieve it.
Now the last question: is DevOps a necessity or ornamental?
It is totally based on your product. If your product is simple and won’t change very frequently, the cost to implement DevOps will be high. On the other hand, if your product is complex and very costly I personally think you should go for DevOps.
Posts
