6

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?

Improve this question
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 ;)
    – Dan Cornilescu
    Commented Mar 16, 2019 at 4:10

2 Answers 2

Reset to default
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 pulling 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.

Improve this answer
1
  • 1
    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
    Commented Mar 11, 2019 at 9:38
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.