Best practices for separating dev, test and production code

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
lneville
Posts: 5
Joined: Fri Jan 20, 2006 11:19 am

Best practices for separating dev, test and production code

Post by lneville » Fri Jan 20, 2006 11:41 am

I am looking for the best way to keep the "in development", "released for testing" and "released for production" versions of a web site project separate, and allow the promotion of a version from one state to the next.

Because this is a web site project with 100s of files, I don't want to try doing this with 'labelled builds'.

Ideally I would like this to manifest as 3 folders in the root of a project, e.g.
Web Site X
-- In Development
-- Released for Testing
-- Released for Production

In Visual Source Safe, the best way I came up with to create this is to start with just the In Development project then share everything into Released for Testing and also into Released for Production. Then pin the files in Released for Testing and Released for Production at the appropriate levels.

This was very good for seeing exactly what was in each state, and comparing each state to the file system. However it is a lot of work to (i) change the pinning on every file in a set of promoted code and (ii) new files created in the In Development project needed to be manually shared into the Released for Testing and Released for Production projects.

Does Vault have any advantages over VSS for managing this kind of thing, or does anyone have a better system?

Many thanks.

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Fri Jan 20, 2006 1:30 pm

When you share a folder in Vault, it really shares the folder, rather than sharing the individual files within the folder. As such, when you add a new file to one tree, it is automatically to all of the shares as well. So, even if you make no other changes, Vault will be easier to deal with than VSS, as it eliminates the need to manually share new files.

lneville
Posts: 5
Joined: Fri Jan 20, 2006 11:19 am

Post by lneville » Sat Jan 21, 2006 4:38 am

That is good news .... and I just realised it presents a problem for my scenario! As soon as a new file is created in a folder in In Development that is shared into Released for Testing and Released for Production, the file appears in both other projects.

Maybe the sharing and pinning idea is not the best way to accomplish this...

New idea: instead of using pins, would it possible to maintain three labels (designating Dev, Test and Production) within a project, and move them up each file's history as versions of the file got promoted between states? I think in VSS this isn't possible because a label is always applied to the most recent version of a file.

Does anyone have a system they use for web projects that works?

mlippert
Posts: 252
Joined: Wed Oct 06, 2004 10:49 am
Location: Cambridge, MA

Post by mlippert » Tue Jan 24, 2006 12:26 pm

lneville wrote:... and I just realised it presents a problem for my scenario! As soon as a new file is created in a folder in In Development that is shared into Released for Testing and Released for Production, the file appears in both other projects.
I haven't actually ever done any pinning, but I would have assumed that pinning the shared folder at a particular version would prevent files added to later versions of the folder from showing up in the pinned share. It sounds like this might mirror what you were doing in VSS but be magnitudes easier to manage, since you can share the folder and then pin and unpin just the folder instead of everything the folder contains.

Mike

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Tue Jan 24, 2006 1:00 pm

Both Greg and Mike are right about using shares and pins - you can pin a folder at a version, and it won't reflect what is in the other share until you unpin it.

Note that file pin also still works as it did in VSS, if you want to pin files in a folder that do not correspond to a specific folder version.

Labeling the folders will also work, as will creating different branches, and then do merges between them (probably overkill for what you want). Vault doesn't yet have a "move label to different version" command, but you can also delete the label and re-apply to the version you want (either current or historical).

So, I think all 3 of these methods would work, you just need to determine which one you prefer and works with your process.

lneville
Posts: 5
Joined: Fri Jan 20, 2006 11:19 am

Post by lneville » Wed Jan 25, 2006 6:32 am

Thanks everyone, that gives me a lot of possibilties to look at.

Dan could you explain a bit more about applying labels to historical versions? Does this mean I can apply a label (e.g. "Production Version") to a particular version of a file, then later move that label to other versions of the file (which are older than the latest version the developer has checked in, but more recent than the last version labelled as "Production Version") ?

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Wed Jan 25, 2006 10:24 am

You can label either a folder or file at any arbitrary historical version.

We don't have have the capability to "move" the label to a different version, but you can always delete and re-add the label to a different version.

If you label a folder at a given version, but then later want that label to contain different underlying file versions than exist at the folder version it was originally labeled at, you can use "label promotion" (available from the Show Labels dialog) to move versions of files within a label.

My advice would be to read the help or simply play around with label promotion to get a sense what it does.

lneville
Posts: 5
Joined: Fri Jan 20, 2006 11:19 am

Post by lneville » Wed Jan 25, 2006 11:35 am

OK thanks, that is very helpful and compelling reasons to get off VSS !

vperez
Posts: 1
Joined: Fri May 05, 2006 9:52 am

Post by vperez » Fri May 05, 2006 10:01 am

dan wrote:We don't have have the capability to "move" the label to a different version, but you can always delete and re-add the label to a different version.
And how difficult would be for you guys to put together a "move" function to do it for us? (just call delete label and re-add label internally), CVS and SVN support moving tags.
dan wrote:If you label a folder at a given version, but then later want that label to contain different underlying file versions than exist at the folder version it was originally labeled at, you can use "label promotion" (available from the Show Labels dialog) to move versions of files within a label.
It doesn't work, this is what I tried:

1. Labeled a folder with "test"
2. inside the folder edited a text file and checked it in.
3. Right click on the file and show labels, I can see the test label as inherited but "label promotion" is greyed out.

Am I missing something?

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri May 05, 2006 10:57 am

vperez wrote:
And how difficult would be for you guys to put together a "move" function to do it for us? (just call delete label and re-add label internally), CVS and SVN support moving tags.
It wouldn't be too dificult to do, we have just not been able to get to it yet. It almost made the cut for 3.5, but had to be moved back a little while longer. It should hopefully be available in the next six months or so.

It doesn't work, this is what I tried:

1. Labeled a folder with "test"
2. inside the folder edited a text file and checked it in.
3. Right click on the file and show labels, I can see the test label as inherited but "label promotion" is greyed out.

Am I missing something?
Label promotion only works for folders right now, and you have to invoke Show Labels on the folder on which the label was applied (you can only promote a folder on which the label was initially applied, not one of its subfolders).

For example, if you label $/foo, you can only promote it if you invoke Show Labels at $/foo, and not at $/foo/a.txt or $/foo/subfolder.

One thing you could do in the meantime to move labels is to rig up something via the command line client, that deletes a label and reassigns it to a new version.

Post Reply