1. Raise the Level of Automation

Remote builds usually need the help of some CI tool, such as GitHub Actions, Travis CI, and so on. In an intranet environment, you can use GitLab CI and add a CI node for automated builds — see my GitLab documentation.

The benefits of automation go without saying: it standardizes processes, saves a great deal of time, and delivers clear returns.

2. It Helps Others Get Involved

A high-spec local development environment tends to produce a large amount of fragmented, non-reproducible configuration. Some of this configuration is for project parameters, some for development and debugging, and some for building and compiling. Switching to another machine or having another person do the development incurs an enormous cost.

This configuration is also part of the project, and developers need to provide a reusable way to share it with others. A project should not be tied to a particular person or a particular machine; being able to take part collectively is one of the key factors in keeping a project vital.

3. Traceable and Reproducible Versions

Releasing a version requires a lot of preparation. At the code level, besides creating a Branch and a Tag, one very important thing is to ensure the version is traceable and reproducible.

After releasing many versions one after another, it is quite likely that you will need to fix one of the earlier versions. Even if you have announced the range of supported versions, you also need to consider being community-friendly; and if an important commercial user needs it, you will break through the limits of supported versions. The end result is that you have no choice but to fix it.

A version being traceable and reproducible means that, several versions later, you can return the repository code to a certain record and use tooling to package that version out. Therefore, the relevant configuration of the build machine is also part of the project.

4. Lower Cost

Compared with giving everyone a high-spec development machine, sharing a single high-spec development machine costs less. The local environment should be used more for editing and debugging, not for compiling and releasing versions; a machine beyond the required quota is unnecessary.

5. Suited to Remote Work

Non-centralized working hours are easily interrupted and the workplace is unstable; the security of development devices is another aspect to consider. In this situation, more work should be handed off to the remote end, reducing the cost incurred by changes in the working environment. It is very necessary to use some SaaS to manage the information flow and to use remote hosts to complete some work automatically. In very short fragments of effective working time, we only complete the creative editing work and commit it. The rest is left to remote automation tools to finish for you.