start of readme on the proper way to do production deployments

[pherris]

@justin808 this'll have to be a document that gets improved overtime but I do know that the pkgr approach will work for prod deployments as we are using this approach on another project.

---

This change is 

[coveralls]

Coverage remained the same at 99.329% when pulling c441fe8 on pherris:master into 9483bf8 on shakacode:master.

[justin808]

@pherris I don't have experience with Elatstic Beanstalk. However, the recommendations probably do not apply to Heroku. CC: @dylangrafmyre

---

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

docs/additional-reading/production-deployment.md, line 3 at r1 (raw file):

#Deploying to Production

Since this application uses a mix of Rails and NPM conventions you should carefully consider your production deployment process. Typically with a Rails application you will "vendorize" your GEM dependencies (commit them along with your code so that the production deployment doesn't risk downloading slightly different versions of your libraries).  

vendorize? I've never done that or heard of that. Old school npm used to suggest saving all dependencies in git. Those days are long gone. Now we have the Gemfile.lock, npm-shrinkwrap.json and yarn.lock.

---

docs/additional-reading/production-deployment.md, line 5 at r1 (raw file):

Since this application uses a mix of Rails and NPM conventions you should carefully consider your production deployment process. Typically with a Rails application you will "vendorize" your GEM dependencies (commit them along with your code so that the production deployment doesn't risk downloading slightly different versions of your libraries).  

With NPM you can shrinkwrap your dependencies (tag a specific version of the dependency for download) but you do not typically commit the `node_modules` directory to your repo. This means that when your application is built, you are generally downloading all of the dependencies from NPM at deployment time. A better alternative is to build your code for production and save/deploy the resulting artifact. This will remove the requirement of building your application from your production servers and guarantee that you are deploying exactly the same code to every environment/server.

I'm pretty sure that my group has never done things this way.

---

docs/additional-reading/production-deployment.md, line 26 at r1 (raw file):

To resolve this, you need to be able to create a production build with dev dependencies and deploy the resulting artifact. This will trigger the webpack build of the productionized assets and move them into the correct location for the Rails Asset Pipeline.

The `pkgr` gem can do this job well, but this tool requires that the build be run on the same os you are deploying to (not a development laptop for example). This is a paid service, but should be able to be run on a EC2 instance with minimal configuration. Perhaps Travis would be another runtime environment that this could work on in conjunction with other CI tasks.

missing newline at end

---

Comments from Reviewable

[justin808]

@pherris Any comments on my comments?

[pherris]

Sorry, I missed your orig. comments. Would you mind walking me through your process for releasing to production? The ideal situation in my mind is to have a single file that progresses through all the environments without rerunning any compilation steps. This ensures that nothing changes between test/prod (based on different machine configurations, changes in a dependency etc). Maybe I don't understand the way you guys already do it though.

For Elastic Beanstalk, when I run eb deploy the code is shipped up to the server and the npm production build is kicked off (in addition to all the gems being downloaded etc). This works, but is not the optimal solution in my opinion but maybe I'm making more of it than I should.

I was able to resolve my original issue by modifying the client/package.json from:

"build:production": "npm run build:production:client && npm run build:production:server",

to

"build:production": "npm rebuild node-sass && npm run build:production:client && npm run build:production:server",

This type of problem would be addressed by not building on the server(s) I am deploying to, but building beforehand and deploying an already built/tested package.

[justin808]

@pherris Our production deploys all use Heroku, which is the standard Rails setup with the Node buildpack. React on Rails modifies the asset precompile to do 2 main things before the regular precompile:

1. Create symlinks in the assets folder for any images/fonts that might be double fingerprinted
2. Create the webpack assets

[pherris]

So, when you start up the server for the first time you are fetching NPM/Gem dependencies and rebuilding the app on each server it's deployed to. I guess this is the rails way but causes problems when the production environment isn't the same as the dev environment.

I was able to get around my Elastic Beanstalk issue as described with the client/package.json change - maybe this process doesn't lend itself to a README because it's really different per environment. Although, it may make sense to at least be clear about what is happening.

[justin808]

@pherris It's very common to create a script that simulates the production environment locally. I do it all the time. The main thing is to use the ENV "production" for both node and Rails, and to run the precompile before testing this. And you have to remember to clear out the /public/assets directory when you're done (rake assets:clobber or something like that).

[pherris]

You're saying that you simulate production locally, create the assets, then... what? do you zip those files and deploy them? or is the deploy to higher environments still re-doing all that same work?

[justin808]

You will want your local script to mirror your deployment script. In my script, I make sure to put in an echo message to remind not to clear out the /public/assets when done!

[justin808]

@pherris Should we close this one? Or are you still working on this one? I'm all for creating a new document for this type of deployment. However, I want to make sure we don't recommend committing either generated files or npm/ruby dependencies.

[justin808]

@pherris How about we close this one for now? I'll happy to reopen if you get more details.