Production deploy

[hansl]

Production build is one thing, production deploy needs to also happen.

This includes moving the github-pages deploy script back in this repo. We will not support 3rd party ember-cli addons for now.

[intellix]

But what has deploying to a Github page got to do with an ng2 app? Will it also support deploying to other locations like Heroku or S3?

[filipesilva]

We are exploring deploying to github-pages, firebase and npm at the moment.

Deploying to github-pages was being done via https://github.com/IgorMinar/angular-cli-github-pages

[markjritchie]

What about file copy deployment support for simply copying the dist folder to a network share?

[filipesilva]

We're not looking to support that right now, mostly just trying to get what we predict being the most common scenarios there.

The production build functionality should give you a fully standalone dist/ folder though, so for now I'd suggest that you could make a npm script that executes your custom deploy. That way you could do npm run deploy and have all the logic in the repo.

[andre1sk]

deploying to github-pages, firebase are most common scenariois???

[jvbianchi]

I think that Heroku is used by a lot of people too.

[filipesilva]

@andre1sk I should have been more specific. Those are the most common scenarios that we can fully cater for from within the CLI, with a minimum of configuration. Heroku, as mentioned by @jvbianchi, would also fall within that category.

The absolutely most common scenario would be custom deploys either on enterprise or outside of it. Those we can't really cater for with automated commands because they're custom, each project would do them differently.

What we can do is offer a dist/ build - which we already do via ng build. From there on that dir can be pushed wherever needed.

For stuff like github pages and firebase though, they have a well defined api and deploy steps that we can help people with, so those are great candidates for integration.

As an example, the current ng github-pages:deploy does the following:

• creates GitHub repo for the current project if one doesn't exist
• rebuilds the app at the current HEAD
• creates a local gh-pages branch if one doesn't exist
• moves your app to the gh-pages branch and creates a commit
• edit the base tag in index.html to support github pages
• pushes the gh-pages branch to github
• returns back to the original HEAD

These are all things that a user can do himself, but they're rote and automatable so that's where we're trying to help.

[ladyleet]

just tried to use this to deploy my ng2 app to heroku. hehe https://github.com/tonycoco/heroku-buildpack-ember-cli didn't work, but not sure if it was just a user error or not.

[emveeoh]

Used angular-cli to:
ng new PROJECT_NAME
cd PROJECT_NAME
ng serve

Worked locally. Then, attempted a push to Heroku and the build fails at the postinstall: typings install script.

remote: npm ERR! node v5.11.1
remote: npm ERR! npm v3.8.6
remote: npm ERR! file sh
remote: npm ERR! code ELIFECYCLE
remote: npm ERR! errno ENOENT
remote: npm ERR! syscall spawn
remote: npm ERR! angulartest@0.0.0 postinstall: typings install
remote: npm ERR! spawn ENOENT

Then, I tried to deploy on Digital Ocean using a Dokku container. Same problem.

[kylecordes]

Our team (https://angularbootcamp.com/) has worked with many developers most often as they are entering the Angular community. In our experience deploying to Github or Firebase are not the most popular ways to deploy Angular code (even though I personally do the things myself). In fact I'm pretty confident neither of these has never even been mentioned as a possibility.

The most common deployment scenario is to a Web server behind a firewall; then to a public facing Web server already hosting other content. Both of these are most often this is done by integrating a Angular application into an overall server-side application which is then deployed jointly.

To ease adoption by these (numerically overwhelming) developers, I suggest that the important part is not a little bit of magic to make it easy for me to push a Angular application onto Firebase; rather it is to make sure that the "dist" output is easily recognizable by folks who have been around the block for a while (and therefore are typically the gatekeepers of what gets deployed) as obviously good. This is mostly a matter of following well-known patterns for production bundling. I put an item about this in a tracker yesterday, #987. The details aren't too important, but I thought it important to mention here that this stuff about Github or firebase looks completely alien to a large contingent of potential and actual Angular developers.

[filipesilva]

@kylecordes I'm getting a bit confused by the argument against github/firebase deploy. You're not the first person to bring it up in this thread but the answer remains the same: the dist/ folder is standalone and users can deploy it any way they need.

The specific github and firebase deploy are mean to address common non-custom deploy solutions. I cannot see a generic ng deploy command for custom setups, except perhaps that it would run npm run deploy and have users add in whatever they want there.

Can you help me understand what is the fundamental disconnect in perception I have regarding this topic? Is it a documentation issue perhaps?