Dontyoudarenottobeaware

Diese Zusammenfassung ist nicht verfügbar. Klicke hier, um den Post aufzurufen.

After I fixed one problem with my zurb foundation gem (downgrading to 5.1.1.0 worked) I ran into other problems when deploying into production environment onto my debian server. Deploying with capistrano or mina is both depending on a working ruby system with all the gems and of course bundler working in perfect harmony. Unfortunately my rvm per user installation did not work that good with my capistrano version 3. And after finding several forks on github I decided to look for alternatives, which meant other users were not happy with the original. I gave mina a try and found it different and interesting enough to use it. And mina works great except bundler was not "showing up to the party". My reason to switch back though was the ability of capistrano to roll back releases. In the end everything pointed to one black sheep: rvm. Right now I am installing rbenv which sounds promising because focussing on little things like it was intend by the UNIX founders with al...

After starting to use refinerycms I ran into some problems with my settings after deploying my app with capistrano. First of all I was concerned with how the cms would work: somebody does something offline, e.g. coding a view and online somebody is writing a page or creating users How would this go together without dataloss? I ask my question and got some good answers - quick as well: deployment to production with capistrano to vserver - consistency question regarding databases and cms settings - NOT heroku Bottom line was: refinerycms is using files for settings online users will just work with the database, offline users/coders do scripting therefore merging is easy For me it was not that easy at all because I used sqlite3 for developement and production and had to tell capistrano how to keep ONE database alive while rolling out releases: in database.yml production:   adapter: sqlite3   database: /var/www/*****/shared/ production.sqlite3   pool...

Hello geeks! When programming rails I was very releaved having git at my site. And lately I was forced to deal with git sooner than expected Normaly I end deploying with this command, and of course before that I checked my local installation: cap deploy This time I had some trouble with my asset pipeline in production mode. Mainly because of the integration of russfrisch's html5 boilerplate. It took me a while to realize my mistake with rescuing my remote installation, because I was fixing my local system with this command: git log # look for hash git reset --hard *hash* # insert you hash where to go back to cap deploy # new deployment of old version Well, this did not work.......................... I forgot the fact my remote git system is used by capistrano to deploy, so I had to set that bare repository back too: git push --force origin *hash*:master # insert the same hash, see 'git log' ...