Forums / General / Managing a project with git

Managing a project with git

Author Message

Benjamin Choquet

Wednesday 17 November 2010 8:04:12 am

Hi,
I'm new both to eZ and to git and wondering what would be the best way to organize my project repository. Hopefully some of you came across the same problems and found different solutions.

I intend to deploy my projects with Capistrano in a near future which implies my repo must contain every single file needed on the webserver (except content related files).

I'm assuming a project consist in the following :
1/ an eZPublish version
2/ several third party extensions
3/ one project specific extension containing designs and project specific settings
4/ server specific settings stored in settings/override/

Project should contain at least project specific files :
- extension/my_project/*
- settings/override/site.ini.append.php

Though I haven't tested it yet, I guess third party extensions can be added as git submodules in my project repo.

My problem really lies in the ezpublish core files, I see 2 ways but each has its flaw :

1/ set the ezpublish repo as a remote and include core files into my project which would add many versioned files I don't really need
2/ add ezpublish as a submodule and symlink root directories to that submodule (design/ -> ezp/design/, kernel/ -> ezp/kernel/, ...) which would not work on a windows working copy

Did any of you guys experience git submodules and tell me if it works alright ? Have you got any other solution ? Which one do you prefer ?

Thx

Ben

Marco Rogers

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

Benjamin Choquet

Thursday 25 November 2010 12:50:13 am

Marco,

Thanks for this thorough reply.

Being new to eZPublish, I hadn't thought I'd need to patch it but I guess I was being over optimistic :). I'll follow your advice to fork ezpublish and main extensions and clone those forks in my project (or rather in a template project that will itself get cloned in news projects).

As for the fake submodules I don't really get the pros over standard git submodules : submodules updates can be automated when deploying and I kind of like my main project to hold its modules version. But I may have missed your point.

About settings and deploying, what about the Noven INI Update extension ? I haven't tried it yet but it seems to be the right tool. Any pit traps ?

Ben

Nicolas Pastorino

Thursday 25 November 2010 6:18:07 am

A small top-note : rare are the cases where one absolutely has to patch eZ Publish's kernel. Most of the project-specific development can be done through extensions usually. And of course, when one needs to patch, the issue should also be filed in the issue tracker : http://issues.ez.no/ezpublish

Cheers !

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Marco Rogers

Monday 29 November 2010 8:00:38 am

Yes, we don't make a habit of patching the core. But the most frequent occurence is when we need targeted bug fixes that have been fixed in a recent version of eZ, but we're not quite ready to do a full upgrade.

:Marco