Was sind Jenkins Best Practices beim Bauen mit Grunt und Deployment mit Capistrano?

Ich baue gerade einen Build-Server in unserem Büro auf und ich frage mich, was dafür am besten geeignet ist. Ich weiß, dass jede Situation nach einem anderen Ansatz verlangt und es gibt eine Million Möglichkeiten, dasselbe Ziel zu erreichen, aber da ich ein Neuling von Jenkins und das Konzept von Build-Servern im Allgemeinen bin, habe ich mich gefragt, ob ich das richtig mache '.

Unser Unternehmen konzentriert sich auf den Aufbau von Websites für verschiedene Kunden mit verschiedenen Plattformen wie WordPress oder Magento. Ich habe jetzt folgendes Setup:

Wir schieben unsere Änderungen an einen Master oder Staging-Zweig in Git. Jenkins fragt diese Zweige ab und führt Folgendes aus, wenn eine Änderung festgestellt wird:

• Ziehen Sie das Repository von Git ( master in diesem Beispiel)
• Verlasse einen Zweig namens build-master
• Setzt diesen Zweig auf origin/master zurück
• Ist npm install , wenn package.json gefunden wird.
• Ist grunt build , wenn Gruntfile.js gefunden wird.
• (Hier ist Platz für andere Dinge wie phpunit oder casperJS Tests)
• Übernimmt Änderungen und schiebt sie zurück nach origin/build-master .
• Führt ein cap build-master deploy aus, damit Capistrano die Bereitstellung auf dem Remote-Server durchführen kann.

Nun habe ich mich gefragt, ob dies eine "richtige" Art ist, einen Build-Server zu verwenden. Ich stoße auf einige logische Probleme. Wie:

Hersteller-Software zum Beispiel. Wenn ich zum Beispiel verschiedene JS-Bibliotheken mit Bower habe (die sich in einem git-ignorierten js/vendor -Ordner befinden), kann ich sie verketten und zu einer verkleinerten JS-Datei vereinheitlichen, damit sie commit in das build-master -repository (für Capistrano). Aber wenn ich PHP-Bibliotheken (zum Beispiel mit Composer) habe, weiß ich nicht, wie ich damit umgehen soll. Diese befinden sich in einem Git-ignorierten php/vendor -Ordner, aber sie müssen in den build-master -branch aufgenommen werden, damit sie auf dem Live-Server bereitgestellt werden. Derzeit mache ich das, indem ich ein .gitignore.build zu meinem Repository hinzufüge, das den php/vendor -Ordner enthält, und überschreibe das vorhandene .gitignore vor dem Commit mit origin/build-master und drücke auf .gitignore .

Und / oder:

Kompilierte Dateien . Wenn ich einige Dateien nicht einbeziehen möchte (wie zum Beispiel CSS-Dateien, die von SASS erzeugt werden), stelle ich diese in die %code% . Aber noch einmal, wenn Capistrano es bereitstellen wird, möchte ich, dass die kompilierte, concatainierte und minimierte CSS-Datei in meinem Repository ist, sonst wird sie nicht auf meinen Produktionsserver gestellt.

Kann mir jemand sagen, ob ich so baue und einsetze, wie es sein sollte? Oder übertreibe ich es hier für mich? Ich bin sehr daran interessiert, wie Leute mit mehr Erfahrung Jenkins, Grunt, Bower, Composer, Capistrano usw. in ihrem Build-Prozess verwenden.