You can't be in the web development field without hearing about DevOps. It's like this thing that everybody knows about, but nobody really understands. Hopefully by the time you finish reading this you'll know what DevOps is and why it exists. It took me a while to figure out its significance, but now I get why it became a thing.
What is DevOps
DevOps is a way of handling the lifecycle of an application. It sticks with the project from the minute the code base is created all the way through the to tenth release of production code. It combines two teams that are kept separate traditionally. The development team and the operations team combine into one.
Usually this means that developers learn how to manage the build and deploy processes for the applications they write code for. That means learning how to use tools like Azure or AWS to manage loads and learning how to automate the deploy process. Developers become responsible for every part of the application from writing the code to deploying the production build that users see.
Why DevOps exists
There are a lot of processes going on behind the scenes of every project. You have to deal with bugs that are being reported by users without making more bugs. Then there's the issue of going through the deploy process every time. Are there tests in place to check the code? Can you be absolutely sure that you are doing everything the exact same way each time?
With DevOps, you get rid of a lot of those concerns. The whole process can be automated which keeps the builds and deploys consistent. When you know that your deploy process is consistent, it gives you the confidence to deploy more often. You won't have to wait for a long cycle to finish before you deploy some minor bug fixes.
You can do smaller deploys more often because you know exactly what is happening at every step. That will make customers happier when they use your application because they see a faster turnaround in the requests they make.
There's also an emphasis on monitoring system statistics in most DevOps tools. You'll be able to react to sudden changes in real-time because they will be reported to you. If your application is getting an unusually high amount of traffic, you might need to upgrade your server resources. You can have that automatically happen with DevOps. It's as simple as changing a setting.
DevOps makes the server-side part of the application a little more friendly to work with. Once you've built your build and deploy pipelines, your code will go through the tests and deploy to the develop or production environment automatically and you don't have to do anything or talk to anyone. Having that kind of access changes the way companies handle their software. It takes some time to get used to, but it's worth the investment.
How DevOps works
Just like with everything else in web development, there are best practices for working with DevOps. They outline the things you need to implement to be fully into DevOps, but not everyone does all the things. Some people only do continuous integration and delivery, while others might do that as well as some microservices. Here some of the best practices.
- Continuous integration: This means that every time you commit code and it gets merged into a main branch, it will go through the automated tests you set up. Any unit tests you have written will be run here. If the commit passes testing then it will be merged with the main branch. If it doesn't then you'll get an email telling you it failed. After you get past the tests, a build will automatically be run for you.
- Continuous delivery: Once you have a build ready, this part will take that build and automatically deploy it. It's usually the next step after continuous integration. You can set it to deploy the build directly to the development or production environment. This part mainly automates the deploys for you.
- Monitoring: After your application has been deployed automatically, you might have certain statistics you need to watch. Memory usage is a big one and so is the number of users accessing the application. Monitoring makes sure that you can get to the cause of server problems and unexpected behavior.
There are a few more, but these are the bare bones of DevOps. Some developers might include infrastructure as code and microservices in DevOps and that's great. It makes the application even better! If you learn how to handle at least the three practices above, you'll be able to handle the majority of projects using DevOps.
DevOps sounded weird when I first heard about it, but it makes sense. Why not let the developer handle the deploys as well? That's a serious question. Do you see any major issues with this or does it make things easier? It's seemed to make things easier when it's setup correctly and a bit of a nightmare when it isn't.
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (9)
A common mistake IMHO is to delegate a "DevOps" role to a separate team that works for the other teams. It leads to the "Ivory Tower" issue. There should be one or more people with DevOps role for each team, because the DevOps needs to be part of the daily work of a software project.
I'd go further; there is no such thing as 'a DevOps' - it's not a job, and it's not a role. It's a mindset and a way of working which everyone in the team has to commit to.
I agree that it's more of a mindset, and I can tell it may take a herculean effort to apply such a mindset for some companies. In my experience, companies that apply software factory principles and assign very specific roles and responsibilities to each employee have a hard time moving to DevOps. After all, a software factory treats software like an assembly line. People get used to the assembly line like Charles Chaplin in "Modern Times".There is little room for innovation, processes are long and tedious and there is a lot of friction between different teams. In these cases, it may be a good idea to have a transition plan where there is a "DevOps" role for each team.
Thank you for this incredibly well-written, concise post! Exactly as you said, DevOps was a term I only vaguely knew about and would hear of with developer circles.
I've seen DevOps throughout a few projects, but not many. Is it fairly new?
DevOps is not only useful but it is also (now a days) vital if you're serious about your software.
Ever since software development became a thing, we have had to deal with integrating, building and delivering our software, but only now we are calling it DevOps.
That's because delivering your software fast has become just as important as developing it well. You either get your product on the market fast or someone else will.
You take the operations burden from the developers to let them focus on developing and apply continuous integration to make sure they move forward and never backwards.
Helloooo from DevOps guy , AMA.
Me me!
What does the day-to-day of DevOps look like?
Ah I did not want to highjack the post, but to answer it quick.
Optimize CI/CD pipelines
Work on Performance on infrastructure
Come up with solvable solutions for Devs problem of any kind
Code
Fix Issues that Dev reported with the infrastructure
Help Dev come up with easier way of doing things.
That is a good list, if you take DevOps as “the group who used to do ops and is now automating its work”. Which is in fact a good path to follow if you are “previous style ops” and don’t want to wait to be automated by developers.