The computer network connects the computers all over the country. As long as there is a terminal that can access the Internet, such as a mobile phone and a computer, you can access the resources of any server on the Internet (including static resources and dynamic services).

As developers, we are the providers of these resources and services. The process of uploading resources to the server and running the service is called deployment.

To deploy the code portion, you need to go through the build process, which is the compilation and packaging process, and deliver the artifacts to the server.

The original deployment method is to build locally and then upload the product to the server via FTP or SCP (sSH-based remote copy file copy) and restart the service if it is back-end code.

Everyone builds and uploads individually, which is difficult to manage and conflicted, so now they build and deploy on a dedicated platform, like Jenkins.

Our code would be submitted to a code base like GitLab, from which Jenkins would download the code to build and then upload the product to the server.

The process is similar to building and uploading directly locally, except that it is easier to manage conflicts, history, etc., and reuse things across projects.

The build/deploy process is initially written in the shell, but writing that is quite demanding and few people know how to write it (I am not). Visual choreography was later supported. The build and deployment processes that can be choreographed are called pipeline.

For example, here is the interface of Jenkins’ pipeline:

In addition to building and deploying, you can also include automated tests, static code reviews, and other tasks.

This automated build and deployment process is called CI (Continuous integration) and CD (continuous deployment).

We still use SCP/FTP to upload the code to do the deployment, but different code running environment is different, for example, Node.js service needs to install Node, Java service needs to install JRE, etc., just upload the code does not necessarily run.

So what to do? How can I ensure that the deployed code is running in the correct environment?

How about managing your environment as part of your deployment information?

Now popular container technology is to do this, such as Docker, you can put the environment information and service startup mode into a Dockerfile, build to generate an image image, and then directly deploy the Docker image.

For example, when using nginx as a static server, a dockerfile might look like this:

FROM nginx:alpine

COPY /nginx/ /etc/nginx/

COPY  /dist/ /usr/share/nginx/html/

EXPOSE 80
Copy the code

This manages the operating environment.

Therefore, the current build product is no longer directly uploading to the server, but generating a Docker image, uploading it to The Docker Registry, and then deploying the Docker image to the server.

Another problem is that both front-end code and back-end code are deployed on our server, sharing the network bandwidth of the server. The front-end code does not change, but the traffic is very large, which makes the available bandwidth of back-end services smaller and supports less concurrency.

Is it possible to separate requests for this part of the static resource? It is best to deploy to a server closer to the user for faster access.

Yes, that’s what CDN does.

There are specialized CDN service providers on the web, which have many scattered servers that can provide the hosting of static resources. These static resources eventually come from our static resource server, so our static resource server is called the source site. But once a request is made, it is cached so that the next request is not made to the source site, which relieves the strain on our server and speeds up requests for static resources.

This solves the problem of static resources taking up too much network bandwidth, and also speeds up resource access.

In addition, static resource deployment also needs to be considered in order, deploying the resources used by the page first, then deploying the page, and adding a hash to the file name to trigger cache updates are more detailed issues.

This is all about web deployment. For apps/applets, they have their own servers and distribution channels. After we build them, we do not deploy them, but submit them for approval on their platform, and then they are responsible for deployment and distribution.

conclusion

The Internet allows us to use mobile phones, PCS and other terminals to access any server resources, services. Providing these resources and services is what we developers do. Uploading resources to the server and running the service is called deployment.

For code, we can build locally and then upload the build to the server via FTP/ SCP, etc.

But that’s not easy to manage, so we have a CI/CD platform for that, like Jenkins.

Jenkins supports visual orchestration of pipelines, which is much easier to use than shell scripting, and can include automated testing, static code checking and other steps in the build process.

Different code runs in different environments, and in order to manage the environment, we use container technologies like Docker. Write environment information to dockerfile, then build and generate a Docker image, upload it to Registry, and then deploy the Docker image.

Static resources and dynamic resources share the network bandwidth of the server. In order to reduce the server pressure and accelerate the access of static resources, we will use CDN to accelerate the static resources and take our static server as the source station. The first static resource request is made to the source site and cached, and subsequent requests no longer need to be made to the source site, thus relieving the strain on the source site. In addition, the deployment of static resources requires consideration of ordering, cache updates, and so on.

This is true for web pages, apps/applets etc. don’t require us to deploy, just submit for approval on their platform, and then they deploy and distribute.

When we talk about deployment, that’s what we’re talking about.