Hi Daan,
On Wed, Nov 18, 2009 at 5:11 PM, Daan Davidsz <[email protected]> wrote:
> Hi Jason,
> ...
>
> Every website will indeed get its own database. I've made a general
> datamodel that will gracefully allow updates.
>
> I also use git quite a lot, but currently don't see it as a good
> update/package management tool for my needs. I'm not looking forward
> to going through all the websites manually and doing a pull/update of
> the submodules. Maybe I am missing the knowledge of some git features
> to grasp its usefulness in this regard. Could you please elaborate on
> your git usage?
>
The model of using git submodules to pull updates into specific projects
works well for us. Generally, we are working with a smaller number (eg
dozens) of large and complex web apps that are totally customized to a
diverse range of client needs. Furthermore, clients are typically paying us
to "change something", and that is an ideal time to do an upgrade
(otherwise, we may leave it alone unless security or other major bugs are
found).
If you have a lot more sites, or desire to upgrade them all at once, then
this is most likely NOT the way to go. But I do suggest you establish a
really through automated testing procedure of any shared components. The
problem with bugs is that we missed something in the first place :)
> My idea was to build a simple version control system into the CMS
> itself. Each module has different versions like 'stable', 'testing',
> 'dev', '1.0' etc. That way I can manage the versions though some
> management interface in the CMS. All websites get the 'stable' version
> of some module, but I can make an exception for site A, which gets
> 'dev', the one I am working on currently. When the 'dev' version is
> stable enough it gets pushed to 'stable' and the current stable will
> be pushed to 'deprecated' or 'old' or something. This is a sort of
> rolling release system with per site exceptions.
>
That sounds cool. I love doing stuff like that. Have you considered using
symbolic links in some fashion, similar to how System V init scripts are
"pointed to" ?
(that may be totally nonsense --- I don't know your project structure).
> I should point out that I strive for very contained modules. Except
> for some data, they don't have dependencies.
>
> At each database upgrade (which are all scripted) we have a file like:
Version-100-DDL.sql
-- the sql to upgrade from DB version 99 to 100
Version-100-ALL.sql
-- a full sql dump (--no-data) of the database after the change (for
historical record)
Hope it all works out great for you!
Jason Garber
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=.
