Prep work for deploying to cloud.gov

[gboone]

These changes allow the Dashboard to be deployed on cloud.gov at a URL like dashboard.18f.gov. The only change that will affect the current staging and production environments is in the go script where ./go deploy has been modified to use an extra config file to account for the deployment at a subdirectory of 18f.gsa.gov.

Before finalizing the 18f.gsa.gov cutover to Federalist and the Dashboard to cloud.gov we'll need to address:

• [x] Any SSL configurations or compliance issues the Dashboard switch has
• [x] Any assets that lost their way in the cutover, so far it looks like the logo is the only one
• [ ] Put redirects in place on 18f.gsa.gov for all dashboard urls to send 18f.gsa.gov/dashboard/{{ requset }}/to dashboard.18f.gov/{{ request }}
• [ ] Make sure the tests pass and features like the preview function as expected
• [ ] Build in continuous integration, automated deployments

[gboone]

@dlapiduz, curious if you have some time to help wire up some automated builds that deploy to cloud foundry?

[dlapiduz]

@gboone aren't we moving this too to federalist?

[dlapiduz]

Re SSL: If you move to dashboard.18f.gov you get all the SSL config for free.

[gboone]

@sharms @dlapiduz after checking in with the team we're thinking Federalist is a better fit. I think that should be much easier to configure, too, yes?

[gboone]

Some more context for :point_up:. I initially thought cloud.gov alone would be easier to do continual deployments. The thinking behind Federalist is: We're not interested in the editor so much right now. This is all jekyll-generated stuff and a little js. Federalist's preview branches would be very valuable for frontend devs working on the site, consistency in deployment environment with @18F/18f.gsa.gov would be valuable since the team working on the site will be the same team working on this project.

[dlapiduz]

Then lets do federalist and we can use the same proxy for both routes...