Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to reduce the productivity of developers". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

# 1: fully invest in micro-services without appropriate tools

When the project works in the overall setup, all the work can be done. The tool chain is ready to handle this whole well, but to change a small part, you need to deploy the whole. You need to run an end-to-end test to verify that everything is still fine. The larger the whole, the lower the efficiency. As a result, the team moved on and adopted micro-services. Their first experience is great, colleagues can carry out separate services independently, deploy more frequently, and everyone is very happy.

The problem begins when the team does not use micro services and pays too much attention to "micro". From a tool perspective, you will now have to deal with more yml files, docker files, dependencies between variables for these services, routing problems, and so on. They need to be updated and maintained. Your CI/CD settings, organizational structure, and total number of people may need to be readjusted.

If you enter the microservice for any reason, be sure to plan enough time to reorganize the tool settings and workflow. Just count the number of scripts in each location you need to maintain. Consider how long this will take, who will be responsible, and what tools can help you control the situation. If you choose a tool, make sure they have a user community.

# 2: containers that have not externalized the configuration

In many cases, containerization is a great technology. However, it carries a value label and may affect your productivity. Containers add overhead from a security perspective and through the necessary configuration and environmental management. If you disagree with some of the team's conventions, the container can also damage your productivity and the developer's experience.

The most common mistake I see is to build configuration files or environment variables into the container. The core idea of containerization is portability. With hard-coded configuration, you will have to start writing files and pipes for each individual environment. Do you want to change URL? Good, please continue to make changes in 20 different places, and then rebuild everything.

Before you start using containers on a large scale and in a production environment, sit down and agree to configuration conventions that are important to you. Make sure this is consistently introduced in code reviews and reviews. Refactoring this experience is painful.

# 3: mistakenly adopt KUBERNETES

Everyone is making a lot of hype about this open source project called Kubernetes. However, it is difficult for Kubernetes to keep running and integrate into your developer process while maintaining high productivity and experience. A lot of things go wrong:

Kubernetes's worst-case scenario: XY colleagues really want to get his hands dirty and find an online guide to getting started. They set up a cluster on bare metal, which works well with the test application. Then they began to migrate the first application and asked their colleagues to start interacting with the cluster using kubectl. Now, half of the team is focused on learning this new technology. Now, the poor man who is maintaining the cluster will work full-time when the second production workload reaches the first. The CI/CD setup is completely unprepared for this, and overall productivity is declining because the whole team is trying to master Kubernetes.

What can be done to prevent this: Kubernetes is a great technology that, if done correctly, can help achieve a PaaS-like developer experience. After all, it is a descendant of Borg. Borg is a platform built by Google that makes it easy for its software engineers to build massively scalable applications. Therefore, it is an open source interpretation of Google's internal platform.

Best practices:

As far as possible, teams should not build and run quasi-system clusters themselves, but should use managed Kubernetes services. Read the comments about managed Kubernetes clusters that best suit your needs. At the time of this writing, from a purely technical point of view, Google's Kubernetes engine (GKE) is by far the best (although the rights architecture is still painful-access issues, Google?) This is followed by Azure Kubernetes Service (AKS). Amazon's Elastic Kubernetes service (Amazon EKS) is also catching up.

Use an automated platform or continuously deliver API. They allow you to run workloads on K8 without the developer seeing them. The complexity of exposing everyone to the entire setting is almost zero. I know the argument that everyone should be able to do everything, but the pace of change is so fast and the degree of automation is so high that it really doesn't make sense.

If the team really wants developers to manage the Kubernetes cluster themselves, they should give them enough time to really understand architecture, design patterns, kubectl, etc., and really focus on it.

# 4: forget to do continuous delivery

Wait a minute, I already have a configuration item tool. A common misconception is that if you have continuous integration settings, you do a good job. You still lack continuous delivery! Many vendors have coined the term "CI/CD tool", which does not confuse you, but if you have Jenkins,CircleCI, etc., it gives you the impression of continuous delivery-this is not the case.

The carefully adjusted continuous delivery setting (whether self-written or as-a-service settings) is the "glue" in the team's tool chain:

It enables all different components from source control systems to CI-Pipeline, from databases to clusters, and from DNS settings to IaC, to be integrated into a simplified and convenient developer experience.

This is a structured way to maintain and manage a growing number of yml and configuration scripts. If done well, this will enable your developers to start the environment dynamically with artifacts built by CI-Pipeline and fully configured with preconfigured databases and everything that has been set up.

It can be used as a version control system for configuration status and has auditable records to record where it is deployed and in what configuration it runs, and allows you to scroll back and forth and manage deployment of blue / green / canaries.

Through well-designed CD settings, you can change the productivity of developers. They enable developers to self-serve, reduce dependencies within the team, and improve the maintainability of settings.

Teams that use these practices release more frequently and faster, showing higher performance and satisfaction overall.

# 5: unmaintainable test automation

Without automation, effective testing is impossible. Continuous delivery brings a continuing responsibility not to destroy anything. You need to constantly make sure that you don't fall into the trap of inverted test pyramids. To do this, you need to be able to run the right tests at the right point in the development lifecycle.

Sufficient CI tools will help you put unit and integration tests in the right place, while CD tools with configuration management and environmental management will help you run automated end-to-end tests in a reliable manner.

Well-done settings allow developers or testers to start a preconfigured environment dynamically. Strictly externalize your configuration and ensure that you have configuration management that injects these variables at deployment time. This has led to many positive improvements:

Run the right tests at the right time while providing effective feedback to the development team

Developers can gain autonomy, and you can reduce the dependence of key people

Quality inspectors can now test a subset of the functional environment

Quality inspectors can parallelize tests, which can save time and test a subset of data.

# 6: manage the database yourself

The teammates who just left are responsible for setting up MongoDB for the client's project and, of course, running it themselves using the open source project. Of course, switching is "perfect", and of course, the database is not properly protected, and one night, it shows where the data should be:

And of course: you check the backup. A syntax error occurred. Now you must reverse engineer all the data. This is a real example that often happens.

Self-managed databases have operational and security risks. They are distracting, boring and unnecessary. Use Cloud SQL or other products and get a good night's sleep. We usually see managed products from companies such as Aiven.io. These companies provide most databases that can be run for you on all large cloud providers, and they are more functional, more mature, and more complex. Moreover, they are usually cheaper and ensure zero locking while providing greater convenience for developers, which I will always want to do if I keep pace with each other.

# 7: go cloudy for no reason

There is a difference between using only clouds and trying to design a system as agnostic and portable. The latter has many different advantages, such as a dynamic environment, and makes more sense than using multiple clouds. Of course, this is a legacy: some teams have been using GCP, while others have started with AWS and are here now. Others include specialization. One might say that GPU runs more efficiently on GCP than on AWS or cost reasons. But to really surface, you need enough size. Simple multi-cloud setup requires a high degree of automation and requires developers to shield configuration and setup tasks. Otherwise, you will end up in scripting hell.

As a general rule: do not be cloudy if it is not absolutely necessary.

That's all for "how to reduce developer productivity". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.