I’m currently working with Git, Git Flow, Gulp and Bower. I’m working on the develop branch and create releases with Git Flow to the master branch. So develop is equal to my local and test environment, release/version to the acceptance environment and the master branch is equal to the production environment. See: http://nvie.com/files/Git-branching-model.pdf. On every environment runs Git, so deploying is nothing more than: git pull origin master.
I’ve got some dependencies like Bootstrap and Font Awesome handled with Bower and I’m using Gulp to watch .less files for “compiling” to css, minifying css/js, etc.
Now toward to the questions: what should be in my Git repository? Let’s say I’m working on a Magento project, it would be overkill to put Magento and all dependencies from Bower in the repository. Currently I’m excluding only the node_modules (for Gulp) and bower_components (contains dependencies) directories, when I run Gulp the .less files from Bootstrap will be “merged” and “compiled” with my project related .less files. The “compiled” .css file is currently included in my repository, else it’s not possible to do a deploy with just git pull. To get it working without having the “compiled” version in Git I’ve to run Gulp on the production server.
-
What is the best method for not having my platform (Magento or WordPress) in my Git repository, but keep the possibility to easily update? I came across this solution: http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git where they’re using Git Submodules. Nice solution, but this way the platform needs to be in a sub directory. Not ideal because I’ve to “hack” to get it working that way (copy the
index.phpand change the include paths, etc). -
What about plugins/modules? 3th party plugins shouldn’t be in my repository too? Only the plugins I’ve created by myself. But not all 3th party plugins does have a Git repository to use with for example Git Submodules. For WordPress it’s just one directory, so in theory it’s possible but for Magento the most plugins aren’t just one directory (they have files in the
app/code,app/design,skin, etc directories). I’ve a lot of WordPress and Magento sites with multiple matching plugins/modules now every plugin/module is in each sites repository. -
Should “compiled” files be in a repository? If you ask me: no, but I’m currently doing it so it’s easy deploying. Is it general to have Bower and run Gulp on a production server for dependencies and to “compile” on the production server right after a
git pull? Continues running a Gulp watcher (like I do locally) on production takes some extra unnecessary resources?
I hope someone can put me in the right direction.
It’s difficult to provide a universal answer that works for Magento, WordPress, and other platforms. My answer primarily targets Magento, but I’m sure that similar concepts could be applied to WordPress and other platforms.
It’s possible to automatically install Magento as a dependency using Composer with magento-composer-installer. You can either use a public mirror, like this one, or set up your own repository. Once you’ve installed Magento itself as a dependency, it should be very straight forward to update it, just like any other dependency.
You can use Composer for modules as well (after all, Magento itself is just a bunch of modules and a few scripts to glue everything together). FireGento has a lot of common Magento modules which can be used with Composer out of the box. You can also set up your own repositories to use with Composer (we do this for internal modules that we use for multiple sites).
As for modules that don’t have their own repositories, well, you have three options: don’t use them (the less modules, the better), create your own repositories for them, or just commit them along with the rest of your codebase.
In an ideal world, your repository should only consist of your own source files. Everything else – whether it’s compiled, installed through a dependency manager, or otherwise somehow automatically created – should not be in the repository.
But we don’t live in an ideal world – it’s painful to run Composer, Bower, Git, Gulp, Sass, and everything else that you’re using on each and every environment that you want to deploy to (development machines, testing server(s), staging server(s), production server(s), and so on).
And what if those dependencies have dependencies? What if you’re using a Gulp plugin that works well on one of your servers, but fails on another one? What if someone makes a deployment and forgets to run some of the required builds via Gulp? Of course, the answer to these questions is testing and automation. You should be able to click a button (or type a command, for the purists) and have everything automatically deploy – a
git pullis issued, the appropriategulpcommands are run, and so on. But unless you have the manpower and manhours to set up such a sophisticated system, it’s not worth it.Overall, we use a combination of the different points above. In the end, we end up committing (almost) everything to the repository – resulting in deployments as simple as
git pullorsvn up. Of course, configuration files (credentials, .htaccess files, and so on) don’t go in the repository, and neither do fingerprinted files (which we manually upload).Fabrizio Branca has an excellent blog post here which goes through many of the described points in order to clean up and upgrade a Magento setup.