While planning our SalesLogix deployment most administrators are worrying about where to put their sync server and how to open the ports for the website and soon they arrive at the “how do we let our developers do their work?” question. Some things to consider are:

• Do you have more than one developer?
• Do these developers have a machine that can handle a full SLX install sans sync/remotes?
• Do you have a staging server for the changes these developers will be making?
• How will you manage the integration of the changes made by these developers?
• Are you planning on using source control?

Most of the answers to the above questions should be yes. If you have more than one developer they should have a machine capable of running SalesLogix, SQL (Express), VS.NET 2008 and you should have a staging server or at least another deployment and setup on one of those machines for integration tests, a plan for managing those integrations and some sort of source control.

Let’s get started

First some nomenclature. At least one thing is commonly misrepresented by myself and many of the people I talk to. The VFS is a table inside the database. The Model is the changes you are going to be making – it is made of up of all of the xml files etc. Most of us call the model the vfs, but the model can be IN the vfs if you choose or exported.

To export or not export the model? I have asked several people in development and all agree – export the model from the vfs to the local file system. This makes compilation and deployment on the development machine faster and allows for source control to be applied. If you are a single developer working on a single project then perhaps you have a reason for leaving the model in the vfs, but probably not.

Now on the SalesLogix server you can have the model anywhere you like. Why? Because when you go to apply your changes to production you can either bundle the changes up from the staging server, copy the changes from project to project (exported project to project in the vfs in production) or backup the model on the staging server and restore it into the model in the vfs on the production server. You are not concerned in production about the time it takes you to build and deploy the few times you are required to do that in production.

Another great reason for leaving the model in the vfs in production is for backups. We are rather adept at backing up our whole database. This is something we have had to do a lot of in SalesLogix over the years so we have gotten accustomed to it. Doing this on the staging server and delivering the whole database to the client was another method. In either case you will export on the developers machines.

Apply Source Control

So now that you have your model exported from production you can get it on some network share and apply source control. We covered this in Boot Camp and it is also covered here. We used Git at Boot Camp and it is pretty awesome, but many of you already have a source control system in place. At this point you “apply” source control to that exported model. With Git this means creating a bare repo and pushing everything into it, with Subversion or others you have other options.

The only real trick is to use something that allows for optimistic locking. Take Visual Source Safe. The default source control for classic asp systems back before 2002 or so. It makes every file in the directory you control read-only. This causes problems with SalesLogix (and many other code systems) because we create new files, they are read-only and not checked out immediately, so then you get write errors. With something like Git you can create files and edit as you see fit and only at commit do you need to realize what you changed, apply a nice comment and then commit.

Just keep that in mind. Both Subversion and Git have their Tortoise UIs and we have videos in the developers subscription showing how to use Git and the PDF from boot camp is also available here.

Now bring in the developers

So the developers have SalesLogix installed on their machines with SQL Express and Visual Studio (if you want it – I suggest you will). They do a pull from the repo to somewhere on their local drive let’s call it “C:\vfslocal” and we will refer to it as “vfslocal”.

The developer then opens Application Architect and probably has only one model in their project workspaces – it is the one from the database they have connected to. This database should be a copy of the production database. It can have a model in it, we just don’t care about it as developers – that is for administrators later on.

Right click on the project workspaces and add a new workspace pointing to the vfslocal you created. Build it and press the run button at the top of Application Architect. You need to have a deployment configured as default and debug to do this, but that is covered well elsewhere. If you do not have IIS installed – that is ok. Application Architect comes with its own development webserver that will be used.

Developers make changes, they commit locally and they push good code up to the repo on the share location. All is well.

When the developers push their changes to the shared repo they are forced to reconcile their changes. This means they cannot go home until they have used a merge tool to ensure their changes are integrated into the code. They really want to do this – that is how they share their work. If this step fails or has a problem and something is overwritten then the source control system has a method for “rolling back” changes etc.

Let’s QA something!

Your staging server will be used here. The point of this step is to get the changes out of source control and into a production like environment. So we do a pull or get from source control of the entire model. If you were choosing to not use source control at this point you would be asking your developers to bundle everything up and send it to you. Either way you gather all the changes, apply them to some model somewhere. For us that is going to be a model in the vfs on the staging server. We want it to be as close to production as possible.

How do we do that? On the staging server (or connected to it) we open Application Architect and create a new workspace pointing to the model we just pulled from source control. It should show in our project workspaces now. Click on the model in the vfs and tell it to import from other project and choose the project you just created. AA will then suck all of the changes from the source controlled model into the vfs.

What have you done?

You have taken the changes that the developers have pushed to the repo and pulled them locally to the C: drive of the staging server and then imported them into the vfs. You can now build and deploy and check for quality as you see fit.

You still need to get them into production, but production can be on the machine next to you or at a client site. At this point you can backup the model in the vfs and restore it to a client production machine, copy the whole database if there were data changes too or create a bundle of all the changes and apply it to production. The options are limited.

What not to do?

Do not place source control on the output files (C:\inetpub\wwwroot\slxclient). This makes no sense. If you want a copy of these files then use a deployment snapshot instead. This was also covered in boot camp and in the various classes offered at Sage.

Do not have more than one developer working out of the database (vfs). This will cause a problem. The easiest one is both developers open AccountDetails, one makes changes and the other just looks at it unaware of each other. Both press save. The LAST ONE to save get his or her changes in the vfs the other one loses their changes forever. It is just that simple. Export your vfs and apply source control. Two ways to not have that happen to you.

Here is a basic diagram of the process as I see it. I have verified this information with several good resources, but comments are welcome and edits may be made :)