SVN Build/Deployment Model Setup for Sage SalesLogix Web Dev/UAT/Prod Instances

I am trying to set up my organization's source control architecture for our Sage SalesLogix Web application. We are using SVN.

We have 3 servers, one dev, two for user acceptance testing, and two for production. Each environment has its own database.

We would like to keep the trunks orderly, but this can be difficult when managing the VFS in the way SalesLogix wants us to.

What I would like to do is this: - Have all developers use the DEV installation instance of SalesLogix in App Arch. - Deploy changes to local machines for local unit testing and review. - When all development work is complete, create a bundle of all the changes in the proposed revision. - One build manager installs the bundle on the UAT installation instance. - Compile and dep开发者_JAVA技巧loy to UAT folders. - On rejection, uninstall the bundle and reinstall after changes. - On acceptance, do the same for Production servers, and commit changes.

While this means we have 3 VFS, it means we are only developing in one, which is, to me, the way to go.

Am I on the right track in my thinking?

---

To be honest I've not used SVN for a SalesLogix model, instead I use Git exclusively with SalesLogix. This is because the way Git works fits better with how SalesLogix and the Application Architect works. In normal cases, the SCM doesn't matter, but it does with SalesLogix. Not to say that SVN won't work well with a SalesLogix model, I know there are some that use SVN with SLX (it just won't be as easy as with Git or Mercurial), but honestly, with preferences aside, the SalesLogix VFS/model really only works well with a fully distributed SCM.

That said, what you describe is how I work with SalesLogix in Git. I work create a dev branch and do all my work there. The master basically reflects what is in production so I can redeploy to production at anytime from master if needed. In the dev branch I do all development and also create feature branches for specific features. Then merge back as the feature is complete. Working this way allows you to develop and test everything out before you've moved it into the production working branch. Once it is ready for deployment I can easily switch to the production branch and then deploy from there. If things are rejected by QA it is just a matter of switching back to the production branch or rolling back commits if needed. Also, working in this way, you really only need a single VFS or model. Not three separate ones as you describe as everything lives on separate branches and only merged into the master branch once it is fully developed and tested.

With all of this, however, I still do maintain separate dev & test systems from production (mainly since I work as a SLX business partner and not a SLX customer), otherwise you have no way of testing bundles for delivery. In the dev system, I use the branching described above to allow me to release fixes into production while new feature development is still underway.

I wish I had more specific SVN info for you, but the concepts are the same regardless of SCM used.