DevOps - why you should care?
It is impossible for a developer to learn anything when someone yells at them for something they broke six months ago - that is why we need to provide feedback to everyone as quickly as possible, in minutes, not months. - Gary Gruver
Many programmers think that software delivery, infrastructure, time to build applications, automation of certain tasks is not on the list of their tasks, this is not their worry … Unfortunately, they are very, very wrong. Modern software development is not only associated with the delivery of appropriate solutions, high quality, but also with the time in which it was made and delivered. If you don’t automate, you are unfortunately behind your competitors, and you don’t know how much knowledge is at your fingertips. The knowledge that can often save your skin.
If you want to speed up your tasks, build faster, ship faster to production, lost of manual tasks and operations, lack of monitoring, slow recovery rate, Low deployment frequency, slow recovery rate, simpler deliver value faster to you customers you really should care about DevOps. Probably many of you have same problems.
Manual deployment is a pain that is caused by manual changes or complex deployment process.
The Death of DevOps (as we know it) https://t.co/I0x3lUnOwd #devops #docker #kubernetes— アンドリュー·ドバイ (@AndrzejDubaj) February 19, 2020
Manual deployments are basically quicker at the beginning but further than can be harder to deploy a lot of versions in a short time. Depending on the size of your application, whether you’re using multiple virtual machines to e.g. distribute it via load balancer and maybe you’re doing a (micro)services solution? Doing it manually for the first time is probably ok, but doing the same things (updating the source code being spread out across multiple servers etc.) tends to become really cumbersome. One of the main things that you think of when someone talks about DevOps is Automation. This is so important in DevOps that is impossible to see a DevOps process without it.
The more you automate the fastest you will be, basically in all areas: pipelines, tests, security, building and switching infrastructure if needed. When we talking about infrastructure we should also build infrastructure as a code and eliminate any manual ad-hoc task and fixing. And yes DevOps is for everybody. In today’s world customers have grown increasingly intolerant of software that is buggy, unstable or not secure. Any company that needs to deliver quality software faster needs to care about DevOps and the supporting practice of continuous delivery (CD), which enable continuously building, testing and deploying software infrequently, incremental releases.
Any automation done well should enable fast flow and providing work visible, build quickly. The main goal is to decrease the amount of time required for changes to be deployed in production and to increase the reliability and quality of those services. Set up a build server is a project engine that allows providing fields to automate various tasks. Another important part is the feedback. If you want to know if something fails, you must get this information. If you fail, fail fast and recover even faster. That is the purpose to build your infrastructure as a code and automate the process of recovery from fail.
Build server and hosting environment - these two points give you a lot of flexibility and stand as the core of CI & CD. The first thing is you need a place that you will host your application. Second, you need to set up a build server that will build your code, test it and push it to the given server environment, upload artefacts to FTP server or beta apps to the internal storage. Everything will happen automatically after a new commit to the repository. If you spend a day, maybe a little bit more to set up your build server it will be time later, by saving time that would be unnecessarily spending on manual deployments, uploading files and some other manual tasks. But this is still, the first step. The next step is to create a separate test environment, on which will be run integration tests and after they change to „green” the build server will receive a message that it’s safe to push the new release to the production environment. Even for your mental health is better to push some changes when it was built, tested and run.
Less than a third of developers take responsibility for security https://t.co/f28V5NzIhK— アンドリュー·ドバイ (@AndrzejDubaj) February 19, 2020
This is an endless cycle. To achieve Innovation you need first to think about the Cultural Transformation that will enable DevOps and continuous learning. Then from there, see how you can change the steps in your process. The world is changing, technology and your business are changing, and you can always learn from the mistakes made during this journey. Today there is no only DevOps but also: DevSecOps, MLOps, DataOps, IotOps.
- Understanding the Differences Between Agile & DevSecOps - from a Business Perspective
- The Phoenix Project
- 10 Deep DevOps Thoughts From Chef’s Jez Humble
My site is free of ads and trackers. Was this post helpful to you? Why not