preface

As the saying goes, an engineer who doesn’t like to make a wheel is not a qualified engineer. Today brings the latest small tool wheel, the previous VUE component platform server is about to expire, and will enter the secondary development, so it may not be accessible for the time being (should be after mid-March), now has not played the big guys can go to see oh. PM me!!!!!!!

Today brings not only a practical gadget, but also a model for standardizing the development process of a project. The specific model will be explained later. The primary purpose is to reduce the probability of problems during the project development process, which requires us to standardize the management of development and subsequent processes, and also make our engineers comfortable.

Project engineering

Project engineering is not only about the extensibility and maintainability of the code we write, but also about how to make our whole development process efficient and stable.

The problem solved by engineering is how to improve the production efficiency of coding, testing and maintenance.

So how can we as good engineers not have a good engineering concept?

By now, you can recall whether the overall process of the current project is clear. If so, you can imagine the following questions:

  • Test whether new feature development or bug fix is the first time to know the test
  • Is the test code already modified by you, and is the code deployed to the test environment
  • After the completion of the test merge online, temporary function emergency offline can accurately carry out the code rollback
  • Is it possible to know exactly what is being submitted each time
  • Is your code often conflicted by colleagues, causing problems

These problems are I encountered in the actual development, so in the concept of engineering we development, testing process will appear no standard, it is very uncomfortable. This uncomfortable I want to how to change, and then to think about how to optimize these non-standard things. (Lots of text warnings)

Project Iteration process

This is my summary and analysis of the process based on the understanding and understanding of the existing company.

The above picture is interpreted as follows:

  • Reduce bug correlation by automating branch creation and forcing one bug or requirement to one branch (preventing multiple bugs + requirements from being submitted at once, which is a nightmare for code rollback)
  • Developers standardizing commit information can also reduce the amount of work associated with Git and the task repository
  • Mr Requests are easier to make from the command line
  • Triggered by playing tag automatic update, at the same time also can send automatic generation version of the log to make test test (need to explain here in the task actually has been released, but in practice often appear delay and the problems in advance, cause development cannot optional completion of tasks, need to wait for version again after turning his task to test, In this way, the development can directly complete the task after submission and enter the area to be verified. The test passes the test of release log selectivity.
  • If a function does not need to be rolled back or a bug modification error occurs, the git submission record associated with task information can be used to confirm the submitted content. At the same time, because a branch corresponds to a bug or requirement, the code interaction between tasks can be greatly reduced

Of course, the process specification of so many words is not suitable for the development of every project, but overall I think it should be regarded as an iterative process of a standard project.

If your project doesn’t fit, check out the tools below directly to see if they work.

Throwing bricks leads to jade

After the above analysis, we can get a development-test cycle. Since we said that we built a wheel at the beginning, let’s take a look at the function of the wheel first, and put a fragment of the project MD document.

Note: The dimension of wheel support at the present stage is jIRA + Gitlab workflow. (Of course, you can modify it yourself)

// Automate the COMMIT process
'lzgit lz / lzgit l'

// Automatically obtain JIRA and COMMIT information
'lzgit commit / lzgit c'

// Modify scaffold base configuration information
'lzgit config / lzgit cf'

// Submit the Mr Request
'lzgit mr / lzgit m'

// Automatic push
'lzgit push / lzgit p'

// Modify the overall configuration
'lzgit config / lzgit cf'

// Create a new development branch
'lzgit branch / lzgit b'
Copy the code

If you don’t understand the above commands, you can look at the detailed execution process of the following key instructions to understand the specific function.

lzgit commit

This directive replaces our overall commit process, which runs as follows

lzgit mr

This command will automatically publish Mr Requests on Gitlab as follows

lzgit branch

This instruction will automatically create the development branch, the branch created by this instruction, can submit information without filling in the selection

lzgit lz

This instruction is a complete set of processes to complete the development, and will automate commit, push, and Mr Request operations

lzgit push

This instruction is a simple branch pull and then push operation

lzgit config

This instruction is to modify the configuration of some procedures, relatively simple to try to understand

lzgit

In fact, the above has said so much about the use of lzgit and some processes, so what is the lzgit thing how to use? That’s what I need to say here.

To sum up the following key points:

  • Node-based environment
  • Write in TS
  • It follows that NPM is used for package management
  • The code is hosted on Gitee

Of course, I’m a front-end developer and I’m based on NodeJS, but there’s no limit to how much I can use. I just install nodeJS in my environment and I’m ready to use it.

Install command

npm install -g lazy-git-cli

Tool profile

A support for Git submission, Jira association, Mr Merge request submission, release log generation and branch management tool development, only need to do a simple configuration to generate project specific file configuration (if branch management is not needed, do not need to configure)

The current management process used by most companies is GitLab + Jira, which can be used as long as your company or project is using this for agile development

Tool summary

If you really read this far you’ll see that there’s one key thing the tool doesn’t do, automate the generation of release logs

It can be seen from the above introduction of engineering process that the test is conducted for bug testing and regression through the release log and JIRA completion list. In this way, double-checking can ensure that we have completed the JIRA test and can clearly know which JIRA has been released and can be tested, while the ones that have not been released cannot be tested temporarily. Efficiency is guaranteed without tests coming back to develop jIRA that have clearly been modified, simply because the test environment was not deployed.

In this brief explanation, this wheel has some limitations for the time being. If someone really starts to use it, I will improve the interface and make multi-end adaptation, so the function is not completely completed for the time being (in fact, it is lazy).

If you want to use the tool, please comment “little brother, hurry to finish XXX” at the bottom, as in: “little brother, hurry to finish the release log generation”.

I:

This article focuses on the process and tools, but if you want to know the overall development techniques, let me know in the comments and the next article will be published soon

The last

At the end of the day, I will publish some addresses for your approval:

  • NPM: www.npmjs.com/package/laz…
  • Gitee: gitee.com/beon/lazy-g…
  • NPM install -g lazy-git-cli