I have experimented with a few setups for development on the web client but this is the one that seemed to work best for me the last few times.  Thought I would write it down to get it organized and maybe see how others worked.

Despite what I wrote before about using version control with SlxWeb we do not systematically check the projects into the central repository anymore.  The reason is that SlxWeb doesn’t jive too well with Subversion.  The files for each project are saved to a central, shared drive.  Each project is actually a git branch, but is also available as the full project backup on the shared drives for devs who prefer not to use git (in which case they have to manually copy the files to their hard drive and back – sounds rather annoying to me but that’s their choice).

As for myself I work with a single git repository on my workstation (or rather, on each of the vm’s that I work from).  I start a project by switching to the "virgin" Slx7.5.1 branch, then creating a branch for the new feature/project:

git checkout SLX7.5.1
git checkout -b QuickTicket

This folder now contains the base "Model" project for SLX 7.5.  Typically this would be under \Projects\SlxWeb.git for me.

I then create a web site called "SmartParts" in Visual Studio and save it under a subfolder off the repository folder… for example \Projects\SlxWeb.git\QuickTicket\SmartParts.  This will be used to contain my custom smart parts.  I could create them directly under the "SupportFiles" under Model\Portal\SlxClient\SupportFiles, and this would be a bit more convenient for deployment, the problem is it would make it hard for me to tell where the custom parts are.

Now if needed I will also create the class library project that will contain my custom business rules (this would be Projects\SlxWeb.git\QuickTickets\QuickTickets.BL) and my unit tests (QuickTickets.BL.UnitTest).  I add all the Saleslogix references to all these projects (I also add a few shared projects to the solution containing some helper methods).

If the project is large enough and is going to contain some custom entities I add the package for them in the Application Architect’s entity model, and add the corresponding assembly to the hibernate.xml file.  It is not perfect isolation of course because we’ll still have to define the relationships from the Saleslogix entities to our custom entities within the Saleslogix stock packages, but it is as good as we can get it with the current system.

At this point I am ready to start work.  If I want to make a new custom smart part I create a folder for the corresponding "Page" (using the same name as in the Saleslogix portal config) in my "SmartParts" web site project, and add all the relevant files to it (ascx, asmx, resx, images, etc).  I have to manually add them as links in the Saleslogix portal config which is a bit tedious but I think the extra isolation is worth this little pain.

Once I am done I need to commit my changes and push the branch onto the main repository:

git add -A .
git commit -m "Whatever"
git push
cd /p/QuickTicket/SlxWeb   (wherever the shared folder is...)
git merge QuickTicket    (here we merge the change onto the shared files)

The last step with the merge is the one that eluded me for a while.  Normally with git the "central" repository (if there is one) would not be used to store files, but in our case we want to make them available for devs who prefer not to use git.  So, the repository on the shared drive is set to track the "master" branch onto which I merge my changes.

I tend to do little work with bundles as I find them tedious to work with – if I need to apply a feature from a project to another I can simply pull and merge the git branch.  But this development setup still makes it possible to create bundles if needed.

That’s about it.  Makes for a rather dull posts, but helps me put things together.