Deploy Process after Webpack RFC

[treznick]

https://github.com/newhavenio/newhavenio.github.io/pull/50#discussion_r170363976

Right now GH pages auto deploys off of a commit to master. This works with our assets because we don't have an asset build system, we just serve directly. If we have an asset build system (that #50 would provide), we need to explicitly commit the built assets.

This issue serves an a point of RFC discussion for how to do that. Please comment below.

[sukima]

I see two options both of which means decoupling master from GitHub pages. First have a master and a gh-pages branch. master is the source and gh-pages is the final build (release)

Then we have a build script that knows how to package the release and then deploy it. For example if using gulp you could use gulp-webpack and gulp-gh-pages. Alternatively, you could directly use webpack with the gh-pages-webpack plugin.

Once complete then it is up to someone to run the build/deploy command which pushes to gh-pages. Or if we still want the master trigger a deploy we would setup a travis-ci integration that watches master and will build then run the deploy command.

[treznick]

yeah, I think we want to do travis-ci to trigger the deploy. Maybe that means we serve off of a gh-pages branch instead of master, and have master auto deploy to gh-pages when it "passes"

(of course, there aren't really tests for this, because it's not really an application - if that needs to change, we should add tests :) )

see https://docs.travis-ci.com/user/build-stages/

and https://pauldambra.github.io/using-travis-to-build-jekyll.html for some details. Looks like we need a key to do the actual push to gh-pages, and to have a separate branch, and to set up travis correctly.

cc @jnimety @NerdsvilleCEO @bsutt123

[bsutt123]

I'm all about making a better build and deploy process, but I wont be able to take this on for at least a couple weeks until I finish some pressing stuff that I have to take care of within the next 2 weeks to a month. Someone else might have to pick up the webpack PR from where it is and incorporate the other parts of the build process.

So I understand that gulp and webpack do different tasks, but do we really need both for our static jekyll page with a smidge of ES6? It feels like adding gulp in as well would be overkill unless it truly does something that webpack can't. I think it looks like Travis is the best route, but I'm not set on anything.

[thatnerdjosh]

@bsutt123 @treznick I think the travisci stuff can go off another branch anyhow and we can base it off if this branch... Merge that into this the webpack branch then the webpack branch into master. Thoughts? I don't mind taking this on, unless someone else wants to

[thatnerdjosh]

Also I'm against the gulp route personally because that is client side, and the deploy is fairly straightforward

[sukima]

So I understand that gulp and webpack do different tasks, but do we really need both for our static jekyll page

You don't have to. There are webpack plugins to deploy to gh-pages. The question is what is more familiar to the widest audience. Some developers know grunt others know gulp and some know only webpack. Heck for that mater we could use Makefiles! It all comes down to a collective choice.

Gulp offers more flexibility and feature sets to do more and more. With webpack it is a very specific task and eventually as things grow you might need more.

I would say we use the tool(s) that whoever is going to need to maintain the Travis-CI build environment knows best.

[thatnerdjosh]

Resolved in #50