Ben Reichelt’s Weblog

We’re constantly tweaking and improving our processes at work when we see an opportunity to grow.  We leverage Sharepoint a lot because its readily available and easy to setup.  We have policies around how we work on projects as far as how we document projects, source control, issue management, etc. with most of these policies involving Sharepoint at some level.

Our process works well – when we follow through on it. Its sometimes difficult to find the discipline to always follow the letter of the law. For instance, I may see something wrong in a project, so I’ll go and fix it, check the change in, and its done.  What I should do is open a new issue, document it, and link my code checkin to the issue so we know what was done to fix the problem.

For processes to be most effective, they need to be followed by everyone on the team consistently, which can be a struggle.  Its especially hard if the processes you want to implement are a pain in the ass for the developers.  Consider a hypothetical scenario where in order to fix a bug you were required to walk around to every developer in your company and tell them verbally that you were fixing a bug, what you were going to do, etc.  It would never happen, its such a waste of time that people would just fix the bug and get on with life.

The best process is one that can’t be circumvented.  In the above scenario, I can choose to not go to every developer, I can just fix the bug. Since that policy has ways of getting around it, you run the risk of some people following it, some people who “kind of” follow it, and some people who flat out ignore the policy.  Instead, if there was some way to guarantee that everyone follows the same procedures, you’ll get the most consistent results and accurate data.  The way you guarantee that everyone is doing the same thing, is to latch on to something that eveyone is already doing.  If there was some action that you know everyone already does and you can somehow associate your process with that action, you can ensure that everyone does it. I think the pressure point that can fulfill this requirement is your source control.

Every developer needs to checkout code from the repository, and they need to check it back in after they’ve made their changes.  Its unavoidable, and everyone is already doing it. If you can inject policies into the code checkin, people have no choice but to complete the necessary actions.  If you require that they’ve entered the bug or feature into your bug/feature tracking application by forcing them to put the issue number in the checkin comments, then you have a good start on getting everyone on the same page.  You can even extend it past that.  You could have them enter the number of hours spent, the estimated hours, etc. and by doing all this as part of a checkin, its going to get done, because it will have to, it can’t be circumvented.

I haven’t research many source control tools to see what kind of existing functionality they have in this space.  I’d be willing to bet that Vault has some sort of policies that can be applied. Not sure about SVN, CVS, or Source Safe.  I do know that SVN has the concept of hooks so that you can write custom apps that intercept the checkin and do whatever you want.  This is something that really interests me, so I’m going to be doing some more research to see whats currently out there.  I think you could have a really streamlined, lightweight process that still generates plenty of useful project data by collecting the data on checkins.

(This entire post assumes that you embrace a process-driven environment, which I believe is not advocated by some of the agile/scrum community, I think they focus more on the people rather than the process, correct me if I’m wrong here.)

We’re using ClickOnce to deploy the windows forms client that I’m currently working on.  ClickOnce is sweet, its awesome to not have to worry about updating your users’ applications, knowing they will get updated the next time they run them, but thats not to say that it doesn’t have its drawbacks.

One problem I ran into was the issue of .config files.  In our app we have some settings stored in the app.config file.  We want to have different settings for our development environments from the production environments.  The problem is that once you’ve created a ClickOnce deployment, you can’t modify the files, otherwise the hash codes won’t match anymore and ClickOnce will refuse to install the application.  After doing some digging and not finding much, we just have separate .config files for development vs. deployment, which is usually the case, but using ClickOnce basically means that you can’t modify the files once they’re deployed, or so it seems.  You can’t just build from Visual Studio and put the files out there, you really need to have a separate build environment setup.  I think I’m going to setup an automated build that will generate the ClickOnce deployment files so that we can alleviate this problem. (I know, I know, we should be doing this anyways I’m just pointing out that its got some barrier to entry sometimes).

One thing that is nice about ClickOnce is the portability of the deployment files.  You have several publishing options, File System, Web Site, FTP site, etc. Since the files need to go from our environment to the client’s environment behind a VPN and firewall, we can’t simply publish the files right out there, we have to publish them locally, then copy the files over to their web server.  Its nice that you can simply copy the files over and it just works, no extra steps neccessary.

Since we are developing a windows forms app, we are taking advantage of encrypting app settings that .net 2.0 introduces, but more on that later.

Whew! I’ve been busy as hell at work lately, which means I get home and the last thing I want to do is sit down at my computer and write.  On top of my own project work, I’ve been helping others get up to speed, as well as other random stuff I’ve been tasked with.

My project at work is a pretty damn cool one though.  I’m converting an asp.net application into a Windows Forms application for one of our clients, using .net 2.0 deploying the app using ClickOnce.  This was an internal web site, so the deployment piece isn’t a huge deal, but its cool to be using the newest technologies, and I’m learning a ton about how databinding works in WinForms 2.0.

I got approval to use the Composite UI Application block to develop the application, so I furiously researched the CAB and did some of the hands-on labs and whatnot.  Doing the labs really helps you understand how the CAB works, as it can be pretty tough to wrap your mind around it.  I still don’t fully understand it, as I started developing the project, my code slowly morphed into a simpler MVP pattern, with only views and controllers, leaving the WorkItems to not really do much at all.  I’m still developing the modules as separate class libaries so that me and the others on the team can develop the modules independantly of each other, and I’m still using the CAB to dynamically load the interfaces into the workspaces at runtime, but I know that I’m not using the CAB to its full power.

The real benefit to the CAB seems to be that you can dynamically swap out interfaces, but I don’t really need that functionality, as the interfaces will always be a pre-defined set.  I am using this feature to swap out whole interfaces based on the user role (Admin, User, Guest, etc.) which makes it a lot easier to do authorization, because in my Admin views I can load all the info I want, in the User views, I only interact with data that is authorized for User’s; so rather than have a bunch of code that is always checking the role of the person who’s logged in, I can simply do the check once, load the appropriate interface, and that it.  Very slick.