Alex,
What I like to do is the following:
- Rather than keep branches corresponding to my environments, I like to use
tags.
- For each release/promotion of a build to staging/production/etc, I
recreate that environment's tag. In the development -> staging -> production
scenario, I typically use a continuous integration build tag for
development, copy it to the staging tag, and copy the staging tag to the
production tag.
There are variations on this basic theme that I sometimes use. Since my
builds are all automated anyway, I usually just reuse the same continuous
integration tool from development for all my other builds. So every build
that's run on e.g. staging gets its own build tag. In cases where
internal/external clients are exposed to these build numbers, I'll sometimes
be asked to e.g. "promote staging build 123 to production". In that case
I'll just copy that build tag to the production tag (so I don't have to
worry about whether build 123 was the latest build or not).
What I like about this approach is that it gives me traceability on what was
promoted to production when, and when it went through what stages of
testing/verification. And by running 'svn log' on the tags' parent folder (I
like to use a trunk/branches/tags/environments set of top-level folders),
wrapped by a little bit of clever scripting, I can quickly dig up exactly
when each environment was deployed to and from where.
Regardless of whether this is useful to you, I would never, ever use merging
as a means of triggering a build/deployment. Too much room for human error,
and way too little room for automation/remote triggering (I like triggering
builds by manipulating these tags through SSH macros from a
Blackberry/iPhone).
Hope this helps,
Rob
On Mon, Sep 14, 2009 at 3:17 PM, Alex <alex.liivid_at_gmail.com> wrote:
> Here is my branch structure
> - trunk
> - branches/staging
> - branches/production
>
> We do you primary development on trunk, and do bug fixes on staging.
> When trunk is ready and stable, I want to merge all of those to
> staging. Our deployment system (beanstalkapp.com) always deploys from
> branches/staging.
>
> I have three choices:
> 1) Merge changes from trunk into branches/staging. I have tried in
> branches/staging:
>
> svn merge --reintegrate http://[url]/trunk ./ --accept theirs-full
>
> but this leaves diffs when I go the root and do:
>
> diff -r trunk/ branches/staging --exclude=.svn
>
> 2) Move branches/staging to branches/staging-[date/version] . Then
> copy trunk to branches/staging.
>
> 3) Copy trunk go branches/staging-[date/version], then update our
> deployment system to deploy from the new branch.
>
> I have been doing (2), but I don't really like it. (1) seems to
> better keep track of revisions, but I'm willing to accept that might
> be wrong.
>
> Ideally subversion would support some type of "symbolic link". I
> could have branches/staging-v1.3 and branches/staging could be a
> symbolic link there. This would allow the deployment system to not
> need to be updated every time.
>
> Any thoughts?
>
> Thanks.
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394745
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
--
Polarion Software
Subversion Training & Consulting Services |
www.polarion.com/services/index.php
Download Eclipse bundled with Subversive today! |
www.polarion.com/products/eclipse/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394791
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 23:32:48 CEST