Hello Steven,
I'll try to give some contribution to your questions. I have the same.
SVN will not solve your problem alone. I think you will need some other
tools + process to put this working.
I'm setting up a process for my current project. This is an aproach. If
someone has any other ideas, feel free to contribute. The idea is (based on
the subversion book):
1) Trunk is the has most features and less stability. It's unstable by
default.
2) In a moment, you will do your first QA release. Then you make a branch of
whole repository and call it 1.0.
3) While QA does every tests, your development team will work on new
features. This features will be commited at trunk.
4) When QA finished a test cycle, your corrections will be commited in the
1.0 branch. Then you have two options. Tell your developers to do every
correction commit at 1.0 and trunk or tell your developers to do every
correction only in 1.0 then do a big patch at the end (I never tried this
before). Tools like commit notifiers helps to keep this process really
working. If someone commit a at branch without a corresponding commit to
trunk, then you cut his hands off.
5) Once the corrections is finished, you can tag the 1.0 branch as 1.0.1.
6) New test cycles generates tags 1.0.2, 1.0.3, until someone consider this
stable. Then you compile everything and put in production.
7) You'll make another branch for QA. You can call it 1.1. Now you have
trunk for development (unstable), 1.0.x for production (most stable) and
1.1.x (under QA).
8) If a new bug is found, the correction must be made in 1.0, 1.1 and trunk.
9) Every new QA fix goes in 1.1 and trunk.
10) Every new feature goes on trunk.
11) The cycle continue for every new release.
The question is. How can I send only the differences to production, QA, or
wherever I need?
SVN provides a very, very beautiful tool for source control. This is not the
only problem. There's a lot of other ones.
- Continuos Integration: To assure all your "live" branches to be
compilable. There's a lot of tools for a lot platforms (Java, .Net, Delphi,
and many other stuff). Most of them with integration with subversion.
- Building tools, like ant, nant and other stuff, to make these build
scripts easier.
- Tools to build documentations
- Tools to build installer (most of the build tools do that).
In my company, I'm currently working on a differential build machine.
Something like that:
1) Get sources from 1.0.1
2) Get sources from 1.1.0
3) Look for differences, file to file. For every source file modified,
identify the affected binary. Mark the binary as "needed in differential
build".
4) Compare SQL scripts between the releases. Compile the differences to a
new one.
5) Pack it all, in the structure needed for publishing.
I think this kind of tool must be built especially for your needs. Some
applications has heterogeneous technologies, dependencies and make it more
difficult.
I don't know if this kind of discussion is completely off-topic. If it is,
feel free to mail me in private.
[]'s
Eric Lemes
On 6/5/06, Steven Lavallee <stvcinlav@yahoo.com> wrote:
>
> Yes, sorry I will describe the process.
>
> We are setup with one trunk that the developers use to
> check in (unit tested) their changed code. A UAT TAG
> is created each day to migrate the changes to UAT.
> The issue is I do not know how we are going to get the
> code that has been approved in UAT to QA because the
> TAG that was created for QA contains approved and
> unapproved code. I thought that a QA branch could be
> used to handle the changes moving forward. Is there a
> way to mark the approved code so that it can be
> checked out for migration to QA and PROD?
>
> Thank you,
> Steve
>
>
> --- Andy Levy <andy.levy@gmail.com> wrote:
>
> > On 6/5/06, Steven Lavallee <stvcinlav@yahoo.com>
> > wrote:
> > > Thank you for the information.
> > >
> > > I do not understand how the code migrates to
> > > Production after it has been approved in QA. Not
> > all
> > > of the code in a TAG for QA is approved. We have
> > > weekly migrations to Production how do pieces of
> > the
> > > TAG get moved to Production?
> >
> > How things migrate really is dictated by your team &
> > process. SVN is
> > just a tool that holds your project artifacts. It
> > doesn't enforce
> > anything that you don't set it up to (via hook
> > scripts and/or process
> > management).
> >
> > Only tag what's supposed to move to production. If
> > you can't isolate
> > those elements, then you need to re-evaluate your
> > strategy, your
> > source layout, or your choice of SCM tools. Or,
> > create branches from
> > 100% approved versions and ONLY change items that
> > can be approved
> > (then tagged & released) within a week. But that
> > will quickly become
> > a branch-management nightmare.
> >
> > Perhaps if you could describe for us your full
> > process, someone could
> > propose a more workable solution. Giving details in
> > drips and drabs
> > will just prolong the confusion, and may send you
> > down the wrong path.
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Received on Tue Jun 6 05:35:40 2006