+1 to what has been said before. If deploying with every push to master (or whatever you use as a production branch) is a bit too fast and loose, and you want to see an example of how to manage branches with longer lead times between deployments, take a look at https://github.com/nvie/gitflow.
It’s a git extension that adds some branch workflow to less-manually support having one of the more common sets of branching structures/workflows. It may well be overkill for you, but be aware of it. AB > On Feb 2, 2015, at 9:46 AM, Jarin Udom <[email protected]> wrote: > > I'd also strongly recommend including your URL endpoints in your JSON > responses, if you can't use relative paths for whatever reason (actually it's > a great idea even if you are using relative paths). jQuery.ajax() is totally > ok with relative paths, by the way. > > For example: > > // /things.json > { > "things": [ > { > "id": 123, > "foo": "bar", > "_link": "http://example.com/things/123 > <http://example.com/things/123>" // Use POST, PATCH, etc methods for > different behavior > }, > ... > ], > "_meta": { > "total_count": 1024, > "page": 1, > "per_page": 20, > "total_pages": 52, > "prev": "", > "current": "http://example.com/things.json?page=1 > <http://example.com/things.json?page=1>", > "next": "http://example.com/things.json?page=2 > <http://example.com/things.json?page=2>" > } > } > > If you have to use absolute paths, you can hard code the initial resource > path into your page (or use some other discovery method): > > <script> > var window.thingsUrl = "<%= things_url %>" > </script> > > > On Sunday, January 11, 2015 at 7:42:57 PM UTC-8, Benjamin Wanicur wrote: > Hi Andrew > > Having 2 separate repos to support separate environments sounds awful and > deadly :) I think it's reasonable to have separate branches for development > versus stable production, but that really does not have much to do with your > environment. And disclaimer in advance that my answer is a bit rushed as I > am working through some issues of my own right now.... > > But I would look into not hardcoding that kind of environment data into your > codebase. Check out this Rails guide: > http://guides.rubyonrails.org/configuring.html > <http://guides.rubyonrails.org/configuring.html> > Heroku also makes it really easy to add environment variables to the > different heroku apps, so that can help you with some configuration (having > ENV variables in your config code instead of hardcoding) > > As for your specific example, you can use something like this to make your > URLs flexible by environment: > > Rails.application.routes.default_url_options[:host] > etc.... > > So I think your issue (or at least the one you mention) might be more of a > config issue rather than deployment. > > Cheers > > Ben Wanicur > > > On Sun, Jan 11, 2015 at 6:08 PM, Andrew Haines <drewh...@ <>gmail.com > <http://gmail.com/>> wrote: > Greetings Fellow Problem Solvers, > > I want to open up a quick discussion on best practices for deployment of > Rails apps. > > As my application has grown, I have found that each deployment has become > more and more of a pain. > Certain files on my local code have changed slightly from files on the > server. For example, I have ajax calls written in javascript and the URLs > are hardcoded. So for my local code, the url would be > localhost:3000/something. On the server it is > https://hourslogger.com/something <https://hourslogger.com/something>. This > means I can't just upload all my files at once, or I will introduce bugs that > will break the app. I can't just have the app break because of the number of > users we have. > > I currently run the app on Digital Ocean. I have 2 Git repos; one for the > local code and one for the production server. My current deployment process > is to keep a list of the files that are different and upload those files > individually. I assume all the other files are the same (meaning local = > server). I feel like this is error prone/ hacky so I wanted to ask for > advice. > > I am building out my test suite to try and catch these problems when they > happen, but is there a better way to deploy or a best practices to follow? > AKA Tools where you can deploy with a click of a button, and not have it > break the app. > > I appreciate any help from software gurus greater than I =) > > - Drew Haines > DevCo > > > > -- > -- > SD Ruby mailing list > sdr...@ <>googlegroups.com <http://googlegroups.com/> > http://groups.google.com/group/sdruby <http://groups.google.com/group/sdruby> > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sdruby+un...@ <>googlegroups.com <http://googlegroups.com/>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby <http://groups.google.com/group/sdruby> > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
