There’s a lot written about how the way developers structure their daily work can cause unproductivity. An example is when unnecessary meetings are scheduled across the day so nobody can get into deep focus mode.
There’s a lot written about how the way developers structure their daily work can cause unproductivity. An example is when unnecessary meetings are scheduled across the day so nobody can get into deep focus mode. Today I want to look into the biggest killers in developer productivity: the way you configure and setup your DevOps workflow. In almost all situations I’ve come across there were some quick-wins that help you avoid most of the problems.
When teams work in a monolithic setup everything sort of works. The toolchain is prepared to handle this one monolith well, but yes, changing one small thing requires the deployment of the whole monolith. End to end tests need to be run in order to verify that everything is still fine. The bigger the monolith is, the less efficient this will be. So the team goes ahead and adopts microservices. Their first experience is great, colleagues can work on individual services independently, deployment frequency goes up and everybody is happy.
The problems start when teams get carried away with microservices and take the “micro” a little too seriously. From a tooling perspective, you will now have to deal with a lot more yml files, docker files, with dependencies between variables of these services, routing issues, etc. They need to be maintained, updated, cared for. Your CI/CD setup as well as your organizational structure and probably your headcount needs a revamp.
If you go into microservices for whatever reason, make sure you plan sufficient time to restructure your tooling setup and workflow. Just count the number of scripts in various places you need to maintain. Think about how long this will take, who is responsible and what tools might help you keep this under control. If you choose tools, make sure they have a community of users also using them for microservice setups.
Containerization is an awesome technology for a lot of situations. However, it comes with a price tag and can have an impact on your productivity. Containers add overhead from a security perspective and through the necessary configuration and environment management etc. They can also hurt your productivity and developer experience if you don’t agree on certain conventions as a team.
The most common mistake I’m seeing is: building your config files or environment variables into your container. The core idea of containerization is portability. By hard coding configuration, you will have to start writing files and pipelines for every single environment. Do you want to change the URL? Nice, go ahead and change this in 20 different places and then rebuild everything.
Before you start using containers at scale and in production, sit down as a team and agree on what config conventions are important to you. Make sure to consistently cover this in code-reviews and retros. Refactoring this a-priori is a pain.
Hire our Dedicated DevOps Developers who have in-depth skills and expertise to develop an interactive and secure web application. Get custom DevOps solutions for your project.
Looking to hire top DevOps developers at affordable prices? **[Hire DevOps Developer](https://hourlydeveloper.io/hire-dedicated-devops-developer/ "Hire DevOps Developer")** from **[HourlyDeveloper.io](https://hourlydeveloper.io/...
Our original Kubernetes tool list was so popular that we've curated another great list of tools to help you improve your functionality with the platform.
At some point we've all said the words, "But it works on my machine." It usually happens during testing or when you're trying to get a new project set up. Sometimes it happens when you pull down changes from an updated branch.
Devops for Databases look like a perfect match. Database Devops can function like a well-oiled machine that ensures successful implementation of your devops strategy.