Keep it Professional – Multiple Environments
- by AjarnMark
I have certainly been reading blogs a whole lot more than writing them the last several weeks, and it’s about time I got back to writing. I have been collecting several topics and references for blog posts…some of which will probably just never get written as the timeliness of the topics fade over time. Nonetheless, I’m back, and I think it is time to revive my Doing Business Right series, this time coming from the slant of managing a development team rather than the previous angle of being self-employed. First up: separating Dev, Test, and Prod. A few months ago, Colin Stasiuk (@BenchmarkIT) wrote a great post about separating your Dev, Test/UAT, and Prod environments. This post covers all the important points such as removing Developer access from both PROD and UAT, and the importance of proper deployment (a.k.a. promotion) procedures. I won’t repeat it all here, go read the original! But what I do want to address is what I believe to be the #1 excuse people use for not having separate environments: Money. I discussed this briefly in my comment on Colin’s post at the time, but let me repeat it here and expand on it a bit. Don’t let the size of your company or the size of its budget dictate whether you do things professionally or not. I am convinced that most developers and development teams would agree that it is a best practice to have separate environments for development, testing, and production (a.k.a. Live). So why don’t they? Because they think that it means separate servers which means more money. While having separate physical servers for the different environments would be ideal, it is not an absolute requirement in order to make this work. Here are a few ideas: Use multiple instances of SQL Server and multiple Web Sites with Headers or Ports. For no additional fees* you can install multiple instances of SQL Server on the same machine. This gives you a nice separation, allowing you to even use the same database names as will appear in PROD, yet isolating the data and security access. And in IIS, you can create multiple Web Sites on the same server just by using Host Headers or different port numbers to separate them. This approach does still pose the risk of non-Prod environments impacting performance on Prod, but when your application is busy enough for that to be a concern, you can probably afford one of the other options. Use desktop PCs instead of servers. Instead of investing in full server-grade hardware, you can mimic the separate environments on old desktop PCs and at least get functional equivalency, if not performance matching. The last I checked, Microsoft did not require separate licensing for SQL Server if that installation was used exclusively for dev or test purposes*. There may be some version or performance differences between this approach and what you have in Prod, but you have isolated test from impacting Prod resources this way. Virtualization. This is of course one of the hot topics of the day, and I would be remiss if I did not suggest this. It is quite easy these days to setup virtual machines so that, again, your environments are fairly isolated from one another, and you retain all the security and procedural benefits of having separate environments. So the point is, keep your high professional standards intact. You don’t need to compromise on using proper procedure just because you work in a small company with a small budget. Keep doing things the right way! By the way, where I work, our DEV environment is not on a server. All development is done on the developer’s individual workstation where it can be isolated from other developers’ work for the duration of writing the code, but also where the developers have to reconcile (merge) differences in code under concurrent development. This usually means that each change is executed multiple times (once per developer to update their environments with the latest changes from others) giving us an extra, informal. test deployment before even going to the Test/UAT server. It also means that if the network goes down, the developers can continue to hum along because they are not dependent on networked resources. In fact, they will likely be even more productive because they aren’t being interrupted by email…but that’s another post I need to write. * I am not a lawyer, nor a licensing specialist, but it appeared to be so the last time I checked. When in doubt, consult an expert on the topic.
