<p>There are now two possible solutions: One NPM only one, and a clean one.</p>

<p>First the NPM One (where im not quite sure what exactly will work):</p>

<p>I just googled "npm deployment" and found 3 different Plugins which do exactly that what you want ( <a href="https://www.npmjs.com/package/ssh-deploy-release" rel="nofollow noreferrer">1</a>, <a href="https://www.npmjs.com/package/deployment" rel="nofollow noreferrer">2</a>, <a href="https://www.npmjs.com/package/deploy-app" rel="nofollow noreferrer">3</a>) and there are many more. Which now you suits you best, will be your choice.</p>

<hr>

<p>Now the cleaner one (because we are in the DevOps Stackexchange ;) ):</p>

<p>Use a Dedicated Service (self-hosted or provided) to build and deploy your application.
This way you will just commit your sourcecode into the VCS and the build system will build your Artifact. Then you deploy it through there via it's possibility for it.</p>

<p>As Example i used Atlassian Bamboo quite often for that. </p>

<ul>
<li>I commited my code</li>
<li>Bamboo gets a Trigger to build</li>
<li>Bamboo run the Build with the Tests</li>
<li>Bamboo create the Artifact</li>
<li>now you had the Choice to automatically deploy the Artifact or wait for a manuell Button press inside the UI

<ul>
<li>if automatically it will start a Deploy Task</li>
<li>else on Button Press</li>
</ul></li>
<li>The Deploy Task is the configuration how it will be Deployed.

<ul>
<li>in your case: copy the ZIP, extract it, run the deployment.sh</li>
</ul></li>
</ul>

<p>One thing beside that all. One thing i would never do is to build ON the Live system. Sourcecode on the Live Server (even Javascript one, which is most of the time minified) is a big attack window. Beside that you could get many weird behavior due weird things that the different systems do inside the building of the artifact (like different dependencies or things like that)</p>

CC BY-SA 4.0
2019-02-08T08:50:33.253Z
Amazing, and I agree regarding the source code on the live server. I knew I could build it on there. My NPM script is pretty decent in that using even using different systems builds without any issues. So yes, I think the NPM route is actually what I want at this stage. I'll try and update this ticket when I get back, and I'll be sure to mark your answer correct too. (I'm away for ~2weeks from today)
shanehoban
CC BY-SA 4.0
2019-02-07T16:45:14.557Z
2019-02-07T16:45:14.557Z
Serverfrog
<p>Welcome to devops.stackexchange.com. </p>

<p>What works best is dependent upon the team. Find a good tool for the team and perhaps change that when the circumstances change. Also you might do a little thinking ahead to work out what approach might be best fit for the near future (e.g., will my team expand? will my number of servers expand? will I have a security audit in the future?)</p>

<p>Another key question is what capacity or curiosity do you have to explore a few options. If someone is trying to learn devops thinking about getting work at a startup then learning the latest free SaaS tools is a good idea. If you want to work in a regulated industry then a different set of tools are more appropriate.</p>

<p>Always the first place to start is “what do developers using the same languages and frameworks do?” As another answer says you should look at npm plugins to see how they deploy. We can think of that npm as “an ecosystem” and it’s a good idea to follow the crowd for a while to understand what’s normal in terms of, say, managing configuration differences between test and live environments.</p>

<p>In the npm world (say, node.js or reactjs) one typical way to manage setting is a <code>.env</code> file. If it has passwords are you confident about putting that file into git? Consider using git-secret to encrypt the file into git. What happens if you have a settings for local laptop, another for a test server and a third for a live server? How to you manage which one is used when you deploy to which server? Well npm lets you add any number of “scripts” into your <code>package.json</code> and you can have it rename the <code>.env.live</code> or <code>.env.test</code> to be <code>.env</code> on the server when you run the script as an npm command to deploy to either live or test servers. </p>

<p>Many advanced readers will cringe at that simple suggestion. These is because as well as the developer ecosystem there is also the deployment ecosystem. If you deploy into Kubernetes then it has featured like configmaps and secrets that are designed to share config and passwords between many applications. If you deploy to VMs in a company that uses, say, Ansible then its worth while looking at how that ecosystem managed configuration. </p>

<p>Pushing out code directly from your laptop to a couple of servers using an npm command isn’t acceptable at most companies. Did the developer remember to commit the code to source control? It would be a nightmare to have a bug in live but not know exactly what code is running there. For a hello world app that’s not a problem. For a massive reactjs app and a real business application it is a very real problem. The standard solution to this problem is to use a build server or more exactly a “CI/CD pipeline”.  That stands for continuous integration / continuous delivery. It will check out your code from git, then build and deploy automaticafrom to the correct servers.</p>

<p>If you are a startup using a SaaS build service is probably the way to go. Take a look at circleci, travis, bitbucket or any number of free for small teams build pipeline services. If your code is in git they can be setup to build and deploy your code “in the cloud” every time you push code to git.  They can be configured to deploy successful builds to your servers.</p>

<p>Regulated industries typically don’t build in the cloud (so far, that’s changing fast). They tend to pick a CI/CD build pipeline product to setup and manage themselves. Which ones they tend to use is “an ecosystem choice”. The C# world will use Microsoft products. The Java world often Jenkins is a default answer. So if you are learning with the intention of working at big companies it’s worth investing time in getting to know such products. They will be confusing at first as they solve problems that aren’t problems for solo developers who can use simpler approaches as described above.</p>

<p>Devops is a journey of continuous improvement not a destination. Start small and get something working. Then consider how it might be improved and upgrade the approach as needed to work more efficiently with less risks of errors through better automation. </p>

CC BY-SA 4.0
2019-02-08T12:55:11.340Z
2019-02-08T12:55:11.340Z
simbo1905
<p>I use NPM to build my web project, and it does so nicely to a little ZIP file. Keeps everything nice and light, and I can easily keep bloat down.</p>

<p>My current process is to use an FTP client (Win SCP), to upload the ZIP file, and then I have a little deploy.sh script that simply removes the old site, and unzips the new site to the same folder.</p>

<p>I want to be able to build this and deploy it all in one but cannot seem to find the answers. I'm not really sure where to start. I know I could move the build process to the server (git pull, and run the npm command there) but I would rather always have full visibility of the build locally before deployment (ie. could have one script to build, and another to deploy - so yes it technically is a manual deployment, but only manual in the sense that it is triggered).</p>

<p>If this is posted in the wrong place, please advise - any help greatly appreciated!</p>

CC BY-SA 4.0
2019-02-07T12:29:25.887Z
To understand that Correctly: You Build manual on your local machine, then you push the code manual with WinSCP from you local machine to the singel Server. Then you run a deployment Script that comes from *somewhere* on the remote Server which then unzip the locally build ZIP File. Am i correct so far?
Serverfrog
CC BY-SA 4.0
2019-02-07T15:30:06.463Z
@Serverfrog yes that is correct. I execute the deploy script via WinSCP also, so it is quite easy to deploy for me, but I'd like to either be able to deploy it all automatically via the script, or with an additional parameter such as -deploy (which I can manage).

I guess I would need to SSH in anyhow to execute the script, which may be possible with NPM actually after some googling. Maybe there is an NPM library for e.g. FTP access also
shanehoban
CC BY-SA 4.0
2019-02-07T16:30:32.300Z
WinSCP uses SCP which uses SSH to Copy files. so you logging in per SSH.
Serverfrog
CC BY-SA 4.0
2019-02-08T07:34:12.643Z
The question is definitely in the right place :-)
simbo1905
<continuous-integration><deployment><continuous-deployment><build-pipeline><npm>
How to deploy a ZIP or WAR equivalent (built locally via npm)?
shanehoban
# How to deploy a ZIP or WAR equivalent (built locally via npm)?

(Asked by: username_0 on 2019-02-07)

I use NPM to build my web project, and it does so nicely to a little ZIP file. Keeps everything nice and light, and I can easily keep bloat down.

My current process is to use an FTP client (Win SCP), to upload the ZIP file, and then I have a little deploy.sh script that simply removes the old site, and unzips the new site to the same folder.

I want to be able to build this and deploy it all in one but cannot seem to find the answers. I'm not really sure where to start. I know I could move the build process to the server (git pull, and run the npm command there) but I would rather always have full visibility of the build locally before deployment (ie. could have one script to build, and another to deploy - so yes it technically is a manual deployment, but only manual in the sense that it is triggered).

If this is posted in the wrong place, please advise - any help greatly appreciated!

**Tags:** continuous-integration, deployment, continuous-deployment, build-pipeline, npm

> **Comments:**
> **username_1**: To understand that Correctly: You Build manual on your local machine, then you push the code manual with WinSCP from you local machine to the singel Server. Then you run a deployment Script that comes from *somewhere* on the remote Server which then unzip the locally build ZIP File. Am i correct so far?  
> **username_0**: @username_1 yes that is correct. I execute the deploy script via WinSCP also, so it is quite easy to deploy for me, but I'd like to either be able to deploy it all automatically via the script, or with an additional parameter such as -deploy (which I can manage).  I guess I would need to SSH in anyhow to execute the script, which may be possible with NPM actually after some googling. Maybe there is an NPM library for e.g. FTP access also  
> **username_1**: WinSCP uses SCP which uses SSH to Copy files. so you logging in per SSH.  
> **username_2**: The question is definitely in the right place :-)  

---

## 2 answers

### Answer by username_1 on 2019-02-07. Score: 1

There are now two possible solutions: One NPM only one, and a clean one.

First the NPM One (where im not quite sure what exactly will work):

I just googled "npm deployment" and found 3 different Plugins which do exactly that what you want ( [1](https://www.npmjs.com/package/ssh-deploy-release), [2](https://www.npmjs.com/package/deployment), [3](https://www.npmjs.com/package/deploy-app)) and there are many more. Which now you suits you best, will be your choice.

---

Now the cleaner one (because we are in the DevOps Stackexchange ;) ):

Use a Dedicated Service (self-hosted or provided) to build and deploy your application.
This way you will just commit your sourcecode into the VCS and the build system will build your Artifact. Then you deploy it through there via it's possibility for it.

As Example i used Atlassian Bamboo quite often for that.

* I commited my code
* Bamboo gets a Trigger to build
* Bamboo run the Build with the Tests
* Bamboo create the Artifact
* now you had the Choice to automatically deploy the Artifact or wait for a manuell Button press inside the UI
  + if automatically it will start a Deploy Task
  + else on Button Press
* The Deploy Task is the configuration how it will be Deployed.
  + in your case: copy the ZIP, extract it, run the deployment.sh

One thing beside that all. One thing i would never do is to build ON the Live system. Sourcecode on the Live Server (even Javascript one, which is most of the time minified) is a big attack window. Beside that you could get many weird behavior due weird things that the different systems do inside the building of the artifact (like different dependencies or things like that)

> **Comments:**
> **username_0**: Amazing, and I agree regarding the source code on the live server. I knew I could build it on there. My NPM script is pretty decent in that using even using different systems builds without any issues. So yes, I think the NPM route is actually what I want at this stage. I'll try and update this ticket when I get back, and I'll be sure to mark your answer correct too. (I'm away for ~2weeks from today)  

---

### Answer by username_2 on 2019-02-08. Score: 1

Welcome to devops.stackexchange.com.

What works best is dependent upon the team. Find a good tool for the team and perhaps change that when the circumstances change. Also you might do a little thinking ahead to work out what approach might be best fit for the near future (e.g., will my team expand? will my number of servers expand? will I have a security audit in the future?)

Another key question is what capacity or curiosity do you have to explore a few options. If someone is trying to learn devops thinking about getting work at a startup then learning the latest free SaaS tools is a good idea. If you want to work in a regulated industry then a different set of tools are more appropriate.

Always the first place to start is “what do developers using the same languages and frameworks do?” As another answer says you should look at npm plugins to see how they deploy. We can think of that npm as “an ecosystem” and it’s a good idea to follow the crowd for a while to understand what’s normal in terms of, say, managing configuration differences between test and live environments.

In the npm world (say, node.js or reactjs) one typical way to manage setting is a `.env` file. If it has passwords are you confident about putting that file into git? Consider using git-secret to encrypt the file into git. What happens if you have a settings for local laptop, another for a test server and a third for a live server? How to you manage which one is used when you deploy to which server? Well npm lets you add any number of “scripts” into your `package.json` and you can have it rename the `.env.live` or `.env.test` to be `.env` on the server when you run the script as an npm command to deploy to either live or test servers.

Many advanced readers will cringe at that simple suggestion. These is because as well as the developer ecosystem there is also the deployment ecosystem. If you deploy into Kubernetes then it has featured like configmaps and secrets that are designed to share config and passwords between many applications. If you deploy to VMs in a company that uses, say, Ansible then its worth while looking at how that ecosystem managed configuration.

Pushing out code directly from your laptop to a couple of servers using an npm command isn’t acceptable at most companies. Did the developer remember to commit the code to source control? It would be a nightmare to have a bug in live but not know exactly what code is running there. For a hello world app that’s not a problem. For a massive reactjs app and a real business application it is a very real problem. The standard solution to this problem is to use a build server or more exactly a “CI/CD pipeline”. That stands for continuous integration / continuous delivery. It will check out your code from git, then build and deploy automaticafrom to the correct servers.

If you are a startup using a SaaS build service is probably the way to go. Take a look at circleci, travis, bitbucket or any number of free for small teams build pipeline services. If your code is in git they can be setup to build and deploy your code “in the cloud” every time you push code to git. They can be configured to deploy successful builds to your servers.

Regulated industries typically don’t build in the cloud (so far, that’s changing fast). They tend to pick a CI/CD build pipeline product to setup and manage themselves. Which ones they tend to use is “an ecosystem choice”. The C# world will use Microsoft products. The Java world often Jenkins is a default answer. So if you are learning with the intention of working at big companies it’s worth investing time in getting to know such products. They will be confusing at first as they solve problems that aren’t problems for solo developers who can use simpler approaches as described above.

Devops is a journey of continuous improvement not a destination. Start small and get something working. Then consider how it might be improved and upgrade the approach as needed to work more efficiently with less risks of errors through better automation.


---

