|
Tuesday 23 November 2010 2:48:16 pm
Benjamin: We are also developing a process for managing ez builds through git. This is our current plan: We have our own clone of ezpublish, the github repo is a remote We have multiple clients and each one gets it's own clone from our master clone. This means we clone the whole ez repository. This may seem unnecessary, but we sometimes patch core files. Those changes are kept client-specific and still versioned in git. And if we want to pull it back into our master repo we can do that easily as well. Plus you can still branch anytime you want. Branching is very cheap in git. It does not copy all files like subversion does. In this full build, you want to remove certain subfolders because they are content folders or they change rapidly with server operation. - ez/var/cache - ez/var/storage - ez/var/log. These folders are in git so that they get created on initial deployment, but completely empty and no files ever get checked in there. For rollouts, there are only a few subfolders that change heavily. - ez/design - we actually use siteaccesses instead of extensions for sites - ez/settings - global override settings as well as settings for each siteaccess - ez/extension - custom extensions as well as any changes we make to built-in extensions (ezfind, etc) Usually these subfolders are the only things that get rolled out to production after initial deployment. Design and extension folders can usually be auto-copied. But if you're going to copy the settings folder, you must make sure that all of the settings are production ready in git. Otherwise, part of your rollout must be a step to check these files and update them to production settings. Probably the latter because we find it's hard to keep people from checking in development settings. If you want to manage extensions separately from the main repo, I think you'll find submodules okay. There is just an extra step to initialize them when you first do a checkout. But you also might want to look into "fake" submodules which allow you to version extensions separately, but still have them as a first class part of each project repo. This is handy for production deployment because all of your code comes with initial checkout and your scripts don't have to manage the main repo plus submodule repos. http://debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb I haven't used this technique at my company yet, but I've used it personally and it works well. Just a little more maintenance when developing. I hope some of this info is helpful. :Marco
|
