Ways for Dev - Test - Prod Implementation

[jdelarco]

Hi,

Can someone tell me if there is a way or different ways on how to structure or implement my repository(ies) on a dev - test - prod environments, so we can eliminate moving files bettwen environments manually.

Thanks

[Beth]

Can you explain to me what your current methodology is? That will help me formulate an answer.

[jdelarco]

Hi,

We want to implement Vault to help us with our source control in development, but we are having problems not only at the development level, but also when manually(using windows explorer) moving code from dev to test and from test to prod.

Is there a way to integrate these three environments in Vault? Maybe having different folders or branches in the same repository, one for dev, one for test and one for prod, so we can eliminate manually moving files, and at the same time having version or source control on all our environments.

Or, how other development companies are doing this?

Thanks for your help.

[Beth]

There are many different ways of going about this.

You don't have to have a physical representation of development, test, and production inside of Vault, but I have seen companies do it before.

Do you make any coding changes in test and production? If not, then if you want a physical representation of those areas, you could use sharing and pinning, or you could make snapshots. This will result in a large tree, but will allow you to have a physical representation of each inside of Vault. I can explain more on this if you really want to go this route.

If you are making changes in testing and production, then you might be better served by not having those areas represented inside of Vault. The two locations where people test or put production code, can either be set up as shadow folders to be automatically updated, or a user can perform a Get from Vault to those areas, or a script can be written to update those areas as needed.

Here, we follow the methodology laid out in Eric Sink's Source Control How To. We have a "trunk" which is our development area. When code is ready for release, it gets labeled and branched. The trunk moves forward to the next version. In the branch, bug fixes and updates can happen and be merged back to the trunk. We use Cruise Control for our builds which pulls the code, builds it, labels it, and saves it where QA can get it for testing. This is a very simplistic explanation, but we can delve into this further yet.

Other articles you may find helpful are:
Best Practices for Managing Branches
Basics of using Label, Cloak, Share, Pin, Branch and Merging

All are found in our Vault KB article index.

Read the information I've provided and then if there still confusion or you're not sure which questions to ask, send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread and we'll talk further about it.