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! [email protected] 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?

[kylecordes]

Perhaps it is just a matter of the right documentation. Here's how I think it should be focused to maximize adoption. Wherever we talk about deployment, always present it in the following order:

1. Optimized production ready deployable web assets.
2. Integration with server service deployment.
3. Fun easy path to deploy on firebase, Github, may be some other readily addressable static hosting.

(Even then though, I'm not sure it really fixes the challenge I was talking about. The people I work with almost universally are doing big corporate scaling things. When they see words like Firebase and Github, to some extent they may interpret these as signals of "oh, this tool is for other people, this tool is not for people like me". I love the idea of built-in easy support for deploying certain places and I wanted to remain there, but presenting it in a way that avoids this signaling problem could remain tough.)

[filipesilva]

@kylecordes I think that makes a lot of sense, to lead and document the topic in that order. I'm also seeing a lot of questions about server config, which I don't think is an A2 topic but we could cover the basics of how it should be done for A2-style apps.

[jasonswett]

If it helps anybody, I wrote a post yesterday on how to deploy an Angular CLI Webpack project to Heroku.

[skdhir]

I second what @kylecordes said.
After adobe abandoned / donated Flex to Apache, many Apache Flex applications (specifically in finance world) are moving to HTML5 / Angular / Typescript platform.
Any large trading application or enterprise level applications are deployed on tomcat (if not WebLogic / WebSphere) and has a Java Web Service back-end.
Now I have a nice POC working on my machine using angular-cli but if I cannot deploy to a UAT server (mostly on Tomcat / WebLogic), corporate architect team will not even evaluate it.
May be at the end of my POC I can create and contribute a document for everybody here.

[kylecordes]

@skdhir What we have today should be amply good enough for this. The output of ng build --prod "dist" directory should be suitable to deploy as your web resources, it won't matter what they are served by, including tomcat and Java stuff, no matter at all. The Gitter channel is probably a better place to ask for details if this tip and the documentation are not enough.

[skdhir]

Thanks @kylecordes ... I created a Java Web Project and copied the dist folder in webapps folder of my java project, build and deployed to tomcat using maven and it worked.
So I agree with you packaging with Java or any other back-end is out of scope for angular and what dist has works well.
Problem was there is no documentation (or may be I couldn't find one) saying the same and if you searched web, so many people saying it doesn't work if you have routers etc.

Thanks again.

[hansl]

Considering this "done"; we will support more deploy options later, but for now build your code and deploy it yourself. Next step will be addon support.

[chenkie]

Here's a writeup I did for how to deploy to Heroku in case anyone is interested :) https://medium.com/@ryanchenkie_40935/angular-cli-deployment-host-your-angular-2-app-on-heroku-3f266f13f352#.bqcp67vdl

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}