SVN Best Practices for a shared, multi-site environment

125 views
Skip to first unread message

Geoff McQueen

unread,
May 30, 2010, 10:41:34 PM5/30/10
to SilverStripe Core Development
Hi everyone,

I'm wondering whether any of the experts here can provide any advice
on the best way to set up a shared server to host multiple
SilverStripe powered websites on a single server. We're already using
named based virtual hosting, and my preference is to have a common
core version of the Sapphire framework and the CMS directory, as well
as other components that are commonly shared. However, hard drive
space is cheap, and from what I've seen it might be easier and give us
more flexibility to keep it all together and have n copies of Sapphire
for each site.

The second aspect, beyond the deployment, is the management/
maintenance of sites on an ongoing basis. Through the use of the
SVN:externals method, I'm wondering whether we can create our own
repository for the 'mysite' content, and then tell via externals tell
the SVN client when they do an update of the whole site, they should
also check/update the Sapphire and CMS content from the main SVN
repo.

Does anyone have any advice about this? I can see there are
potentially a lot of pitfalls - particular as upgrades should be
managed, with a minimum of surprises, as well as the Sapphire and CMS
folders not really being "common", but instead being able to retain
our own versions and configuring things as we like, only merging in
changes in SS versions deliberately and occasionally - so any advice
from the trenches would be much appreciated...

Geoff

Simon J Welsh

unread,
May 30, 2010, 10:49:00 PM5/30/10
to silverst...@googlegroups.com
When hard-drive space was a problem for me, I had one version of
sapphire, cms and modules and just used symlinks. You just need to
ensure that Apache is set to follow symlinks and you'll need to define
a separate TEMP_DIR for each site in their _ss_enivornment.php files.

> --
> You received this message because you are subscribed to the Google
> Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverstripe-
> d...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en
> .
>

---
Simon Welsh
Admin of http://simon.geek.nz/

Who said Microsoft never created a bug-free program? The blue screen
never, ever crashes!

http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e

windandwaves

unread,
May 31, 2010, 7:00:13 AM5/31/10
to SilverStripe Core Development
Hi Geoff

What we do is the following:

1. each site has a staging and a live repository.
2. we commit the following to the staging environment:
- mysite folder
- theme folder
- a list of svn:externals - e.g. sapphire, cms, blog, etc.... -
whatever is needed for the project
- a .htaccess.sample file
- a _ss_environment.php.sample file
3. on our local dev environments we checkout staging, and we copy the
two sample files and update these with local settings (i.e. the copies
are called .htaccess and _ss_environment.php). We create an asset
folder.
4. we connect to staging site using ssh and do the same thing (setup
local files and create asset folder).
5. we connect to live site using ssh and do the same thing (setup
local files and create asset folder).
6. we develop the site on our local environments, making regular
commits to staging.
7. we lock our svn:externals on the staging site to a specific
revision
8. we go to the live site (using ssh) and merge the (empty) live site
with the staging site.

From here, we can repeat steps six to eight as many times as needed
(e.g. every six months), updating sapphire, etc...

This method works very well for us and I would recommend it. We never
make changes to any of our "svn:externals" files.

I have considered using the symlink method, but it is nice to have the
flexibility to update one site to Sapphire 2.4 without updating
another site. From time to time, we also make temporary changes to
"svn:externals" files, just for debugging purposes, but we never keep
those changes. Having "unaltered" svn:externals is very important and
in almost all cases Silverstripe provides enough tricks to customise
stuff without altering the "core".

We only lock the svn:externals to a specific revision once we go live
because we like to make use of updates as much as possible. From time
to time we also come across bugs that we report to trac immediately
and which are resolved before we go live, enabling us to incorporate
them.

The sample files allow us to quickly setup three environments (dev,
staging, live) -and can be deleted after this has been done.

Here is an example of our svn:externals content:

sapphire http://svn.silverstripe.com/open/modules/sapphire/branches/2.3
cms http://svn.silverstripe.com/open/modules/cms/branches/2.3
jsparty http://svn.silverstripe.com/open/modules/jsparty/branches/2.3
userforms http://svn.silverstripe.com/open/modules/userforms/tags/0.2.0/
etc.....

I know it probably sounds a bit simplistic, but it works really well
for us.

Cheers

Nicolaas

Geoff McQueen - Hiive Systems

unread,
May 31, 2010, 7:30:40 AM5/31/10
to silverst...@googlegroups.com
Nicolaas,

Thanks a lot for such a detailed response. That model would work pretty well in almost all circumstances I can think of, however, since I'm new to SilverStripe, I wanted to test one quick scenario.

If we want to add new buttons to the TinyMCE implementation in the CMS, and add the functionality we need around this, would we likely be making changed to the cms/ folder? Specifically, we're looking at implementing a Google Website Optimizer module, which would involve having a feature where the user would select some text, click on an icon in the rich text editor, and have a pop-up which would pull in some PHP generated content. I haven't dug deep enough yet, but I'm just not sure whether we'd be able to leave the cms/ and the sapphire/ directories alone.

Given you've had a lot more experience with SS, would you recommend following that path of keeping sapphire/ and cms/ quarantined, or should we think about using SVN's vendor branch methods: http://svnbook.red-bean.com/en/1.1/ch07s05.html?

Geoff

Hi Geoff

Cheers

Nicolaas

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To post to this group, send email to silverst...@googlegroups.com.

Biagio Paruolo

unread,
May 31, 2010, 7:57:40 AM5/31/10
to silverst...@googlegroups.com
Why you need to create every time asset folder?

2010/5/31 Geoff McQueen - Hiive Systems <geoff....@hiivesystems.com>



--
Cordiali Saluti / Best Regards

Ing. Biagio Paruolo

Red Consulting s.a.s
Via Garibaldi, 1/B - 83025 Montoro Inferiore ( AV ) - Italy
Tel: +39 3928196008 Fax: +39 36 3928196008
Web:  www.redconsulting.it
Email: bia...@redconsulting.it / MSN: bia...@inwind.it / SkyPe:
biagioparuolo
Register Gold Reseller


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

windandwaves

unread,
May 31, 2010, 1:38:05 PM5/31/10
to SilverStripe Core Development
Hey Geoff

I am not familiar with all these SVN techniques (I know they exist,
but I often find them overly sophisticated or I dont have time to
familiarise myself with them), but in any case, it would be better not
to change CMS and SAPPHIRE and Silverstripe ltd. should build them in
such a way that they can be customised without changing their core
code. Often this is harder than hacking the core code but in the long-
run it makes more sense to leave the core alone.

Would /sapphire/forms/HtmlEditorConfig.php be of any help for your
problem?

Biagio,

You do not add the asset folder to your svn repository and hence you
add it every time. We do not add it to the svn repository because the
asset folder is like a database that can be changed by the CMS (the
website admin) and so it should not interfere with the svn repository.

Ciao

Nicolaas

Marcus Nyeholt

unread,
May 31, 2010, 8:07:12 PM5/31/10
to silverst...@googlegroups.com
Instead of SVN externals, I use a phing build system that manages dependent modules (including sapphire and cms) stored in both SVN and Git. 

As for a central codebase, aside from the obvious benefit of being able to have separate sites on different versions, there are times in the silverstripe codebase where realpath() is used (which resolves symlinks), that in some cases causes issues (can't off the top of my head think of when, but it happens). 


Nicolaas

Reply all
Reply to author
Forward
0 new messages