Summary: Performance improvement starts with a little habit, which is the right posture for code management and Commit!
Column planning | Yachun
Volunteer Editor | Zhang Sheng
Software delivery is a code-centered delivery process, in which the functions of code are as follows: First, the final product to be delivered should be clearly described by code; Second, code defines how the system and software work. Third, the code defines what the environment of the system is. It’s all about code.
What about code management and software configuration management?
Let’s start with an example. Here’s a code organization for a team. What’s wrong with this code organization?
Problem 1: Confusing naming of code groups
We found that the top level directory is called risk-managenment, which is a system, and this system is risk management. But the subdirectory says “Qinglong”. I don’t know if “Qinglong” is the application or the team. Then there is a xuanwu below, and there is an aTeam below, which is mixed in Both Chinese and English. Such naming method is very confusing.
Problem 2: Use code blocks to store external binaries
There are a lot of SDK files in Android-SDks, and these files are very large. The code base stores a lot of external binary files, and we know that storing such large files directly in the code base is very costly to the entire code base.
Problem 3: Code with the same ownership is stored in different code groups
There is a data-model in the aTeam directory, but other relevant files are under the basalt, namely data-console, data-task and data-UI. We don’t know what it is, but we know that these files are most likely the same application or product. So it doesn’t make sense that it’s at two different levels.
Problem 4: Common libraries are stored in subcode groups
The next one is common-lib, which by its name is a common library, but this common sense is only used by the sub-code group Xuanwu.
Problem 5: Application documentation (or tests) is stored separately from the application
Finally, there is a docs directory with risk-docs and data-docs, one for the risk control system and one for the data ground system. The documentation is also a code base, the documentation code base and the test code base, and it is stored separately from the application, which is also not reasonable.
What is a good code base organization?
Question: Assuming that all code is stored in a code base and accessible to all, how should the code base be organized?
We consider code bases to be grouped, with code groups (+ subcode groups) + code bases = large libraries.
With this logic in mind, let’s take a look at what a reasonable code group would look like in the example above.
As shown in the figure above, the entire code base is a system with two applications, risk and Data. There are many services and documentation under each application. They have a common Model called common-lib, which all applications rely on. So we put Git repositories that belong to the same application together and let Common go where it belongs. Not by team, but by application group, so that the structure is clearer. Here we summarize some practical suggestions.
- The contents of the code base:
-Product code of the software; – Place documentation (and tests) git repositories under their related application groups; – Do not store artifacts (such as system binary packages) in the code base, in LFS or similar if necessary; (Codeup offers free unlimited LFS storage for enterprises)
- Organizational structure of the code base:
– Organize the code base by system, application, and module hierarchy; – All contents of the same system/application hierarchy are under the same code group;
- Code base visibility:
– The common code base is in a location accessible at its common level; – With the exception of a few code bases such as core algorithms, it is recommended that access to the code base be made public to all relevant persons under the same system/application;
Once the code is organized, developers can collaborate around the code base. The whole codebase collaboration process is Commit everything. Either rebase or merge is a Commit.
So what do we need to know about Commit?
What is a good Commit
We’ve come up with three suggestions for you:
1.Samll
Keep your Git repository as small as possible. Especially with the current state of the infrastructure, although you can have multiple applications in one warehouse, it can be very expensive to maintain. Also on the administrative side, don’t store build artifacts and other binaries on Git. Putting a build artifact on a build repository, while convenient for others, makes it difficult to know whether the build artifact is a product of current code or a previous one, which is hard to trace back to. For binary files, it is recommended to use LFS if necessary (for example, game material).
2.Linear
Avoid meaningless merge and use rebase instead. The next step is to avoid invalid commit lists. There are many code libraries that have long commit records, but 80% of them are invalid. For example, a COMMIT is fix1 or fix2, but you don’t know what it did. Sometimes you can squash the merge.
3.Atomic
Atomicity refers to the atomization of operations. What’s good about atomicity? A Commit solves a specific problem, such as fixing a UTcase, adding a UT or a function, or adding an API. These specific problems correspond to a Commit and are easily traceable. The problem solved can not be very large, can not write 2000 lines of code to solve a feature, submitted together, this is very dangerous. As a developer, the best thing to do is to produce quick, phased results, with constant feedback, and to keep moving closer to the goal. Conversely, the developer experience is bad, and the associated collaborators experience is bad, because people don’t know how much you’ve done and are likely to have mergeconflict with you.
Here are some anti-patterns for Commit:
1. Invalid COMMIT
Such as Mergebranch ‘develop’ of codeup.aliyun.com/abc/xyzinto…
2. The giant commit
A commit involves a large number of code changes and multiple implementation purposes, such as a CodereView (mergerequest, as some mentioned) with over 3000 lines of code. As a Reviewer, you have no idea what the reviewer did, which is dangerous.
3. Semi-finished commit
A commit, for example, that contains a commit semi-finished product with basic syntax problems or poorly implemented code. For example, when it’s time for dinner, hand it in anyway. Such code can’t even compile, which is obviously bad and doesn’t make any sense.
4. Merge branches
The last one is the merge between branches. Develop to master, master to Develop, and once you have a lot of merges, it’s hard to trace the commit because you don’t know where it came from. We recommend that the code base should have a single trunk, and only focus on the trunk merge to avoid the reverse merge situation.
Codeup’s trunk development model promotes lightweight commit reviews and trunk development to help enterprises avoid complex mergers between branches.
Software Configuration Management
Question: Software configurations are often modified and released. Is it code?
Software configuration is another form of code. It’s possible that your actual configuration doesn’t reside in a Git repository, perhaps in a configuration center or some other similar system, but wherever you are, you can essentially equate configuration to some type of code.
The following figure shows the common static configuration and dynamic configuration, or startup related configuration and running related configuration.
Start configuration
- The bootstrapping configuration is built into the image or passed in as a bootstrapping parameter.
- After the startup is no longer modified, there is no need to dynamically monitor its changes.
- Changes to such configurations typically require re-creating or restarting the container.
By analogy, which configurations are relevant for startup? For example, DB connection string, container CPU specification, startup mode, etc. (for example, some pressure testing applications distinguish master mode from Worker mode when starting). Other things like DNS service addresses, things like that we think of as boot-related configuration.
Running configurations
- This is usually obtained and updated by listening on a service or file. Let’s say I want to see what my whitelist is, let me read the whitelist.
- Configuration updates do not require changes to containers and pods.
- The running container continuously listens for configuration changes and automatically takes effect without restart.
Here’s an example of a scenario:
- Change the log level to record only logs at the ERROR level.
- A black and white list of services that are blacklisted to restrict access to certain IP addresses.
- Feature switch, by which a feature is turned on or off.
- Adjust the sampling frequency from sampling every minute to sampling every 5 minutes.
These configurations do not and should not redeploy the application with every change; they are all run-specific configurations.
Let’s take a look at an example of what’s startup related and what’s run related. Let’s list them:
This is a parameter that will be required at startup.
We inject the Secret file into the Deployment and the application automatically senses the value of secret from the file without a restart, so it is a runtime configuration. The higher the internal configuration, the higher the modification cost.
Looking at the configuration from another perspective, it has different layers, code, image, Pod, and system. The configuration in the code is the innermost layer and is the most expensive to change. Therefore, if it is a code level change, it has to go through all the stages before it goes live. If I run the phase, I don’t need to move the front part.
Finally, I leave you with a question: what kind of runtime configuration does it fall into? Welcome to leave a comment in the comments section.
The end state of software delivery is to provide a stable and predictable system. To achieve this, ensure that: 1. Consistency of operating environment; 2. Consistency of software products. So in the next installment, we’ll start to share how to ensure consistency in the operating environment, as well as common pain points and solutions in the environment. Stay tuned!
The original link
This article is the original content of Aliyun and shall not be reproduced without permission.