The Importance of a Consistent Development Environment 

I am again traveling this week, in Toronto speaking at Tech Days Canada 2009, and as luck would have it I needed to complete some work on a few custom DotNetNuke modules for clients on a "Urgent" basis.  So this afternoon I darted off to the speaker room to get an internet connection, just recently I re-formatted my laptop to move to Windows 7, one of the main reasons that I needed to re-format the system was to create an environment that matched my primary development machine, today was the first true test of this new configuration.  Thankfully everything worked as expected and all issues were resolved.  In this blog post, I'll explain a bit as to why it is important when working on multiple environments to have consistent system configurations.

What Must Match?

The first question that is most likely going through your mind at the moment is: what items must be "consistent'?  Well my personal recommendation is as much as possible.  For example the Visual Studio Version, DNN installation location, Module working paths, DNN Versions, and other related folders that might be necessary.

In the case of my modules, each has a build file that creates an installation folder for me, since I have yet to move to MSBuild the paths are hard coded, referencing my folder structure on my primary machine.  Builds on that machine all go to my D: drive and on my laptop prior to the re-install I didn't have a D: drive at all.

So Why Do You Care?

The key point of this exercise is why do I care?  Well this is very simple, if all of the above items match from one system to another, it is possible to simply open your source control system, do a "get latest version" and you can instantly change files and only worry about checking in changes.  If you have environment differences, say for referenced DLL's, or build paths, it might be possible to need to modify files that normally wouldn't be changed, then if you check those in, you wind up breaking your existing development environment.

This is an important thing when working on projects with one developer and multiple machines, as well as when working with multiple developers on the same project.  Establishing a consistent development configuration will help you avoid hassles and problems that can arise from different file paths and references.

 

Posted by Mitchel on Tuesday, September 29, 2009
Tags: .NET 1.1, .NET 2.0, General Tech, .NET 3.5, DotNetNuke Development
 

Comments

I have been thinking about this subject a lot recently. I am going to purchase a new Windows 7 machine soon and I was thinking about doing my development setups in virtual machines rather than in the core of the OS. This would allow me to segregate my different projects/versions/tools, etc and also allow me to send the VM to my laptop when I needed it. If my machines are fast enough with plenty of memory, that should work. Do you think?

By wcmason on Tuesday, September 29, 2009 at 10:07 PM

I now do all of my dev work on a virtual machine. It's way easier to back up your whole virtual disk, and once you get it properly configured, duplicating the box to another system is cake. The only drawback I've come across so far is the lack of dual monitor support...

By andrew on Wednesday, September 30, 2009 at 3:05 PM

When working with teams of developers there will naturally be differentiation/personalization of workspaces. This is why I'm adamant about maintaining a cohesive source tree that keeps all project dependencies and build tools underneath a single project root, with relative paths between them all. With such a structure, the tree can be pulled down into any folder that the developer wants and it will still build. I learned this by reading Mike Robert's philosophy on the subject. Mike has moved on to other things, but the project he started, Tree Surgeon, as well as his article series on source trees can be found here:

http://www.codeplex.com/treesurgeon

By Craig Boland on Friday, October 02, 2009 at 10:24 AM

Craig,

I would agree, however, to get full support for DNN projects some items must still be static between machines. Specifically IIS configuration settings, and project storage related to IIS.

By mitchel.sellers@gmail.com on Friday, October 02, 2009 at 10:36 AM

Comments from the following blog entry: The Importance of a Consistent Development Environment, located at: http://pimpthisblog.com/The-Importance-of-a-Consistent-Development-Environment

By PimpThisBlog.com on Saturday, October 03, 2009 at 12:07 PM

Like Andrew, i also do all my work on a virtual machine. I have used dual monitors with that setup, but it is slow in vmware, and currently not working in virtualbox. Other than that, i am very happy with the setup, I doubt i will ever return to developing in a host machine...

By erik van ballegoij on Wednesday, October 14, 2009 at 5:20 AM

I thought that I read somewhere that the VPC that is to ship with (or shortly) after the release of Windows 7 was to be able to span monitors. Has anyone else heard this?

By wcmason on Wednesday, October 14, 2009 at 6:18 AM

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Friend of RedGate

www.datasprings.com - DotNetNuke Modules ICG Hosting

Click here for advertising information.

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.