Many organization has specialist to plan, design, analyze requirements and translate them into requirements “understandable” for developers. After that developers or as I like to call them coders can start implementation. When they’re done testers test application and some IT person can deploy changes to server where users can start using new features. In this methodology programmers are responsible only for writing code nothing more, they don’t even need to think about what they’re doing.
Later someone invented Software Engineering team, which could take over some of the work. Programmers stopped being mindless code writers. Software Engineering team was responsible for everything that analyst was doing previously. Still when they finished implementation and testing SE team signed off and someone else deployed new code on server.
Finally developers who were interested in IT operations like setting up environments, virtual machines etc. started taking over deployment part. These people were responsible for whole application development life-cycle. From that point one team could carry whole application from planning to deployment.
What’s the difference?
There is one big difference. First methodology and Software Engineering team was depending on individuals like analyst or IT person. When someone left, project was damaged, they needed replacement and needed it fast or project development would slow down.
DevOps methodology removes those limits. Whole team is able to do everything. As in SE team, members are specialized, but everyone should be able to do everything. Additionally DevOps wants to improve the process. They observe and when they see a problem, they start automatizing process. DevOps is all about removing obstacles.
What’s needed?
Unfortunately development team can’t decide they’ll take over whole responsibility. They need freedom and it is common thing that companies want to control everything. Why? It’s topic for another post.
DevOps methodology starts from development team, but it can’t move forward if management is against it. Your organization must want to trust you. If they don’t you’re already done for and the only solution is to change organization, because you won’t be able to progress there.
Abomination of new world
Currently companies deformed DevOps methodology. Real DevOps is culture where developer who is interested in IT Operation or IT person who is interested in software development do something more than their primary job, but right now DevOps is position where only work is to automatize delivery process by setting up CI and CD.
In my opinion it is wrong, because again there is additional person on which team depends. We wanted to remove that dependency aaaand it’s back again. DevOps methodology was there to make it possible for one team to support whole application life-cycle. Not one person to take over IT Operations. Every team member should have basics so he can continue work when other team member can’t.
Continuous Integration
I mentioned some short name earlier, CI. Continuous Integration is practice that required developers to integrate code with shared repository. By integrate I mean push their changes to remote repository. With every push code should be build and tested. Here’s true power of CI. We can create pipeline (process) that will checkout our code and build it on build agent. After build is succeeded it will run automated tests. Thanks to that, developer will know if his code works well with rest of codebase.
CI is very important for new projects. To be honest it should be one of the first thing when new project has started. It’s of course because of developers. We are lazy and it is possible that one of our minor changes that shouldn’t break anything broke everything. I’ve done that multiple times and CI saved me.
Other than that, we can learn immediately that some change introduced new bug. If build fails we know that something is wrong. It depends on how well your team is writing automatic tests. It is possible to setup policy so Pull Request can’t be merged if build didn’t pass.
Still even with manual testing it’s worth to have CI setup. It’s good practice to at least build your code in one central place just to make sure that application can compile without error. It may seem impossible, but it is common problem. If there isn’t any check developers may push code that fails during compilation.
As always it’s easier to integrate smaller batches of code instead of huge feature at once. By introducing CI you’re making your job easier.
Why should I care?
It’s fair question. Every significant company has people who may create build pipeline for you. Why should you bother? I was asking the same question. I was developer, it’s not my job to take care about building code or releasing it. Unfortunately I can’t tell you what changed my mind. I may guess.
Desire to learn new technologies
Docker was responsible for my interest in DevOps at the beginning. I’ve heard about it a lot. It was supposed to improve application development. Whole environment setup with just one command. Additionally to that employers started to put it as nice to have skill I decided it’s worth learning Docker.
While playing with Docker, I started to like it. It’s great that I could deploy my own application and access it from my phone browser, I wondered how it would be to have clients using my application. Because of that I was learning more about Docker and little more time later I found myself setting up CI builds at my work.
Great teachers
Second thing was people around me. In company I worked at that time I had the best teachers in the world. They have everything that is needed, knowledge and patience to teach. I liked listening to them and in no time I wanted to show them my knowledge. Fortunate for me they were fans of DevOps methodology and their views have passed on to me.
Why should you care?
In my opinion it’s good to know even basics. If you don’t like it, you shouldn’t force yourself, but surly you have to know how to setup build. You’re better on the job market when you know something more than everyone else. Maybe you won’t be able to use that skill at the beginning, but who knows. Maybe you’ll hire to project that doesn’t have CI and CD. You’ll be able to shine on the first day. As always all that matter is that you know something more than other developers.
Next time we’ll create pipeline on Azure DevOps.