Using Subversion For SalesLogix Web Development
When I started working on a project at my company, I realized that there was no source control applied to one of it’s critical applications. The results were what you might expect: lost work, inconsistent releases, painful rollback procedures. I was within my rights as a programmer to stand up and say something, so I did.
The result? I was given free reign to implement source control as I saw fit. As long as it was with Subversion. See, all of the other internal company projects use Subversion (every other project outside of this department’s projects is properly source controlled), even though SalesLogix heavily supports using source control with GitHub, complete with supported addins for Application Architect.
The main reasons I could not get approval for Git were:
1. GitHub for “real” development costs money. Sure, it is free, but in order to maintain any privacy or administrative supervision, you need to purchase a subscription. And it’s relatively inexpensive initially, but when added to the costs of managing a new tool and training others on using Git, ROI realization wouldn’t come quickly enough when compared to a free tool that we already know how to use.
2. What if we got hit by buses? If these specific developers left, the organization would be left looking for developers with Git experience, or take the time to break the source control rev cycle to re-apply it to Subversion. Not an option.
3. Saying “it’s secure” isn’t really meaningful. In other words, administrators get more warm and fuzzies knowing that their security practices are the only thing between developers and unauthorized users. Sure, Git says they are “secure, backed up, and always available”, but to the unreasonably paranoid, this isn’t enough. They want to hold the keys and control who gets to use them.
So we couldn’t use Git. I had to use Subversion. The problem here is that Subversion resources for SalesLogix are pretty much non-existent. Sure, source control is straight forward, but there are some subtle nuances with builds in Application Architect that need to be accounted for. So after a lot of trial and error, along with culling information from a few sources that focus on Git integration, I have cobbled together a first pass at using Subversion with SalesLogix web development. As of today, this works.
If there’s something I missed, please let me know in the comments. I want to work hard to make this a living document for others who have a similar task ahead of them.
This assumes you have all the required tools, natch.
1. In Application Architect, back up your current project workspace. This is your fail-safe for the moment if anything fails. Park this in a safe place.
2. Create a new project workspace. Give it a meaningful title. Do not choose the Export Files On Creation option.
3. Perform a restore in this new project workspace that points to your backup.
4. Close Application Architect.
5. Navigate to the directory that contains the VFS model and copy it to a separate location. This may not be needed, but it’s just me being a paranoid developer. I make no apologies for this.
6. At your new separate location, add the folder to your Subversion repository.
7. We’ll now create a working copy directory, so create yet another blank folder somewhere.
8. Do a checkout of the code you added to the repo, and check it out to your working copy directory.
9. Create a new project workspace in Application Architect. Again, do not select Export Files On Creation. Point the folder to your working copy directory.
10. In SVN, set Ignore on the Deployment directory, and modelindex.xml at the root of the project directory.
What you’re left with is development out of your working copy, and once you check everything in, you or someone else can either bundle the changes to your target server, or you can copy the entire Subversion directory to your target server and bind it to your workspace (like you did for this exercise). For multiple developers, though, you will want to make heavy use of KDiff3 or some other diff and merge tool. This isn’t as daunting as it sounds.
I have noticed a few oddities that I’m not sure yet are really oddities. The most pronounced one is that source control is persisted to output files deployed to your local IIS instance. According to the official SLX Training Blog, Jason Huber ends his article with the following statement:
“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.”
I don’t know why, but Windows shows everything in SLXClient as under source control, even though the deployment folder is being ignored. But we are just now starting multiple developer efforts, so I suppose we will learn one way or the other whether this hoses anything.
Efforts to reach out to the SalesLogix development team and other resources for answers to these questions went unanswered. There’s a few postings over at the SLXDeveloper forums that I left that have gone unanswered also.
Resources I used to assemble this article:
Ryan Farley’s blog over at CustomerFX
The SalesLogix Training Blog
Hi Teknophyl. Great article and thanks for the correct pingbacks.
I think we need to differentiate git from github.com. git is superior to subversion for reasons we need not get into. For that matter you could start using mercurial. The point of git is that it works and you can use a service like github.com (which does cost a few bucks).
If you are using svn then you can use git much the same. Just create a bare repo somewhere on a network (where everyone can get to it) and then push there and then you are set. The bare repo becomes the gihub in my scenario.
Github.com is useful if you have developers (one or more) that cannot access your work network reliably.
Git is nice because it compresses the repo much better and there are some neat tricks you can use like rebase etc.
I think the solution that works for you is the best solution though. We presented Git at bootcamp last year and I was working on a simple pluging for Application Architect. CustomerFX did an awesome job with their wrapper of gitgui and that is another reason I like git.
I cannot tell you why your inetpub/wwwroot/slxclient folder is showing under source control, but I am sure you can agree there is no benefit there. I guess it may be nice to have this under SC, but really it is generated code and thus can be regenerated. We did this for a client for escrow purposes for instance.
Thanks very much, Jason. I’ll work on clarifying the differences. What I got hung up on most was the behavior of the SLXClient directory and the initial file setup. I was hoping someone could confirm that this was correct, because right now I’m instructing people to grab the bare repo only after confirmed “good” builds. Otherwise they are pulling from the current version of SC. Make sense?