Correct deploy Symfony2 project with bower.json and grunt?

Question

symfony

Hello!
There is a Symfony2/PHP project that uses Bower and Grunt for front-end development.
Of course, the contents of bower_components and various files minified by Grunt (js, css) do not get into the repository - exactly the same reason why the vendor folder and files like bootstrap.php.cache do not get there.
But we don't want to have a zoo of nodejs, npm, grunt, bower, etc. on the production server, do we? No.
So the only option left is a separate deployer machine on which all our nodejs stuff will be installed. When changes appear in the repository, it will download them, collect, compile / minify everything, and only then upload all the files to the production server with rsync, where there are no nodejs - only what is needed for the application to work.
Can you please tell me if this is the only option?
If so, what did I omit in my reasoning and how best to organize it?
If there are other options - share your thoughts, please.
Thank you.
ZYZH Now everything is assembled on my development machine (because the whole zoo is installed) and rsync is published to the server. I want it to be done by git push.

Answer 1

on the CI server, we make a build (tar.gz/deb/rpm) by git push and deploy it. For deployment, since you are using rsync. you can use things like capistrano / capifoni.
ps I recommend looking towards vagrant + ansible to automate infrastructure management. Or even on docker.

Answer 2

Our /etc/project_name.yml file is managed by Puppet. The project itself is assembled on the CI server into a deb package (bower install, gulp build etc are also done there). The postinstall script of the website package says something like

cp /etc/project_name.yml /var/www/project_name/app/config/parameters.yml

.
That is, the required configuration is already on the server and the package simply copies it during installation. If you need to add a new parameter to the file, then first the json file is edited in the hiera of the corresponding host, it is rolled out to the fronts, and then the package with the site is rolled, requiring a new config key.
In the same postinstall, the script for checking the matching of keys in parameters.yml.dist and the newly appeared parameters.yml is executed, and if the keys diverge, then the installation is considered unsuccessful (read how the developers screwed up with the config, the situation requires manual intervention).
The key point is that neither the developers nor the CI server know anything about the parameters of the combat server and are limited to their area of ​​responsibility.
Well, Puppet already "knows too much" about the infrastructure, therefore, it is not scary to trust this file.