Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-11T09:38:35.460Z
Answers: 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.
Answers: peterh
Answers: CC BY-SA 4.0
Answers: 2019-03-10T14:29:52.123Z
Answers: 2019-03-10T14:29:52.123Z
Answers: chicks
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-12T03:12:01.773Z
Answers: 2019-03-12T03:12:01.773Z
Answers: Jiri Klouda
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-16T04:10:54.897Z
Comments: 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 ;)
Comments: Dan Cornilescu
Tags: <continuous-integration><gitlab><node.js>
Title: How should CI/CD deploy to production environment - copy artifacts or git pull from the server?
UserDisplayName: Lawrence Choy
ThreadText: # 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.
  
  
  ---
  
  