Ich habe mich gerade mit Rails 3.1 vertraut gemacht und einige Zeit damit verbracht, ein altes Projekt zu aktualisieren und herauszufinden, wie sich die neue Asset-Pipeline im Entwicklungsmodus im Vergleich zur Produktion verhält.
Die Standardeinstellung config.assets.precompile segnet nur application.css und application.js , mit der Absicht, dass alles als einzelnes Stylesheet und als einzelne JavaScript-Datei bereitgestellt werden soll .
Offensichtlich gibt es Situationen, in denen wir das nicht wollen, also können wir der Liste in dieser Konfigurationsvariablen Elemente hinzufügen ...
Hier ist die Situation, die ich bei der Produktion mit meinem Sandbox-Projekt hatte:
stylesheet_link_tag ausgelöst.) rake assets:precompile und erneut versucht. config.assets.precompile hinzugefügt und erneut versucht. Da ich nicht wusste, wie ich das angehen sollte, ging ich ein paar Mal im Kreis herum, bis ich dachte, ich hätte alle Assets und die Site lief in der Produktion. Dann habe ich es in MSIE versucht und einen weiteren Fehler 500 getroffen: "verspäteter_png_fix.js" wurde bedingt geladen, und es ist bis dahin nicht aufgetaucht.
Also meine Frage ist, abgesehen von Versuch und Irrtum oder einer starken Abhängigkeit von Integrationstests, wie kann ich vorhersagen, dass meine Site nicht bombardiert wird, wenn die Asset-Pipeline entdeckt, dass einige Stylesheets oder Javascript nicht hinzugefügt wurden die Vorkompilierungsliste?
Ich bin auch neugierig, warum ein fehlendes Stylesheet-Asset die gesamte Seite auf Fehler 500 bringen sollte, anstatt es nur bei Bedarf zu kompilieren oder 404 zu liefern, wenn dieses Asset angefordert wird. Ist dies ein bewusster Entwurf, um früh zu versagen?
Ich habe gerade ein Juwel namens assets_precompile_enforcer veröffentlicht, das sicherstellt, dass Entwickler nicht vergessen, Assets zu config.assets.precompile hinzuzufügen. während sie sich entwickeln. Eine Ausnahme wird ausgelöst, wenn Sie ein Asset über javascript_include_tag oder stylesheet_link_tag hinzufügen und es nicht mit einem Filter in config.assets.precompile übereinstimmt.
Dies bedeutet, dass Asset-Fehler während der Entwicklung abgefangen werden, anstatt nach der Bereitstellung in der Produktion entdeckt zu werden.
Ich hatte ähnliche Probleme mit Schienen 3.1. Das Beste, was Sie tun können, ist, capistrano multi stage zu installieren und einen Staging-Server zu erhalten.
Wenn dies aus irgendwelchen Gründen nicht möglich ist, installieren Sie eine virtuelle Maschine auf Ihrem Computer und versuchen Sie, Ihre Serverumgebung zu replizieren.
Kontinuierliche Deployment ist eine großartige Sache, und Sie sollten zu dem Punkt kommen, wo es so einfach ist, dass es wirklich nicht so schmerzhaft ist. Das heißt, config.assets.precompile kann Regexs nehmen. Wie wäre es also mit einem Standard für die "manifesten" Dateien auf der obersten Ebene der Ritzel oder einem Standard-Unterordner für Dinge, die nicht gebündelt werden? (beachte, dass ich das bisher noch nicht probiert habe ...)
Das mag übertrieben sein, aber das funktioniert für mich (es gibt mir saubere, kompilierte Assets). Ich habe dies in meiner .bash_profile Datei.
%Vor%und dies in meiner config / environments / production.rb (zwingt die Produktion, wenn nötig zu kompilieren; sollte nicht nötig sein, wenn ich mich daran erinnere, zuerst "ggo" auszuführen):
%Vor%Also, mein Workflow ist: 1. Code 2. Git hinzufügen & amp; git commit 3. Wenn ich CSS / SASS / JS / CoffeeScript-Dateien berührte, starte ich ggo. Ansonsten mache ich eine normale Cap-Bereitstellung.
Tags und Links ruby-on-rails ruby-on-rails-3.1 asset-pipeline