<p>There are lots of bad examples on the Internet.  Doing a <code>git pull</code> to distribute code is fabulous for development, but prone to all sorts of issues in practice.  It should not be used for production deploys without careful consideration of the negative consequences.</p>

<ul>
<li>What happens when somebody checks out a different branch?  You'll be sad when you keep <code>git pull</code>ing and nothing new shows up.</li>
<li>How do you verify that the machine is running the expected release?  You can get this from <code>git</code>, but it is easier with most artifact systems.</li>
<li>How do you release to machines that are on an air-gapped network?  Simulating your <code>git</code> server on a private network will be a fun time for you.</li>
</ul>

<p>I'm not sure what format <code>npm</code> uses for artifacts, but it is also probably a good idea to back them up off of the CI/CD server and use a dedicated set of machines for serving up the artifacts.  If you spin up 100 machines at once would your CI/CD server handle it or fall over?  Isolating the artifact serving will avoid your CI/CD server being swamped and useless until the deploy is over.</p>

CC BY-SA 4.0
2019-03-11T09:38:35.460Z
I think, `git pull` should happen from the prod branch. If there is a push to another branch, it should be non-entity for the CI. However, I agree that doing CI of the prod, without a human supervision, is maybe too brave (=risky). But it is imho okay for a demo/test system.
peterh
CC BY-SA 4.0
2019-03-10T14:29:52.123Z
2019-03-10T14:29:52.123Z
chicks
<p>There are some source control systems that bill themselves as artifact management platforms as well (for example Perforce/Helix) and they try to support the mode of work. But git is especially bad at that. You would have to do a lot of work to make git support both development of code and management of artifacts efficiently. I'd suggest to not do that and use a different system for each. JFrog Artifactory for example is a great tool for that. Delivering code in containers and using docker hub for artifact store is another excellent way to do it. Even a bunch of upload/download scripts against S3 are better than storing your artifacts in git, as you might actively slow down the developer experience if you don't setup your solution exactly right.</p>

CC BY-SA 4.0
2019-03-12T03:12:01.773Z
2019-03-12T03:12:01.773Z
Jiri Klouda
<p>We have an internal CI/CD server running private GitLab. It has the source code of our NodeJS project. We would like to run CI/CD and have it deploys to our on-premises production server. (Let's assume we are using the <code>master</code> branch).</p>

<p>Here are two most common methods I found on the internet:</p>

<ol>
<li>Run <code>git pull</code> on the production server, run whatever build tasks needed (<code>npm install</code>, minify, etc...), and restart the service</li>
<li>Build the source codes on CI/CD server, rsync the built artifacts to production server and restart</li>
</ol>

<p>Surprisingly, most of the examples I found on the internet uses method 1. This method requires the production server to have public internet access which may not be possible for many cases.</p>

<p>My question: is method 1 really the best way to deploy a NodeJS application to a production server? If yes, what is the reason?</p>

CC BY-SA 4.0
2019-03-16T04:10:54.897Z
if the production server doesn't have internet access you can't rsync either. And if you use a physical media instead you can use either method ;)
Dan Cornilescu
<continuous-integration><gitlab><node.js>
How should CI/CD deploy to production environment - copy artifacts or git pull from the server?
Lawrence Choy
# How should CI/CD deploy to production environment - copy artifacts or git pull from the server?

(Asked by: username_0 on 2019-03-10)

We have an internal CI/CD server running private GitLab. It has the source code of our NodeJS project. We would like to run CI/CD and have it deploys to our on-premises production server. (Let's assume we are using the `master` branch).

Here are two most common methods I found on the internet:

1. Run `git pull` on the production server, run whatever build tasks needed (`npm install`, minify, etc...), and restart the service
2. Build the source codes on CI/CD server, rsync the built artifacts to production server and restart

Surprisingly, most of the examples I found on the internet uses method 1. This method requires the production server to have public internet access which may not be possible for many cases.

My question: is method 1 really the best way to deploy a NodeJS application to a production server? If yes, what is the reason?

**Tags:** continuous-integration, gitlab, node.js

> **Comments:**
> **username_1**: if the production server doesn't have internet access you can't rsync either. And if you use a physical media instead you can use either method ;)  

---

## 2 answers

### Answer by username_2 on 2019-03-10. Score: 6

There are lots of bad examples on the Internet. Doing a `git pull` to distribute code is fabulous for development, but prone to all sorts of issues in practice. It should not be used for production deploys without careful consideration of the negative consequences.

* What happens when somebody checks out a different branch? You'll be sad when you keep `git pull`ing and nothing new shows up.
* How do you verify that the machine is running the expected release? You can get this from `git`, but it is easier with most artifact systems.
* How do you release to machines that are on an air-gapped network? Simulating your `git` server on a private network will be a fun time for you.

I'm not sure what format `npm` uses for artifacts, but it is also probably a good idea to back them up off of the CI/CD server and use a dedicated set of machines for serving up the artifacts. If you spin up 100 machines at once would your CI/CD server handle it or fall over? Isolating the artifact serving will avoid your CI/CD server being swamped and useless until the deploy is over.

> **Comments:**
> **username_3**: I think, `git pull` should happen from the prod branch. If there is a push to another branch, it should be non-entity for the CI. However, I agree that doing CI of the prod, without a human supervision, is maybe too brave (=risky). But it is imho okay for a demo/test system.  

---

### Answer by username_4 on 2019-03-12. Score: 2

There are some source control systems that bill themselves as artifact management platforms as well (for example Perforce/Helix) and they try to support the mode of work. But git is especially bad at that. You would have to do a lot of work to make git support both development of code and management of artifacts efficiently. I'd suggest to not do that and use a different system for each. JFrog Artifactory for example is a great tool for that. Delivering code in containers and using docker hub for artifact store is another excellent way to do it. Even a bunch of upload/download scripts against S3 are better than storing your artifacts in git, as you might actively slow down the developer experience if you don't setup your solution exactly right.


---

