Setting up a development environment is a very important part of a programmers life. It can be very easy or very hard depending on the architecture of the underlying system. The key differentiator between easy and hard is the amount of server twiddling that needs to happen before the app can run. I believe that, in the long run, servers get tweaked quite a lot, and therefore it's worth solving the problem of setting up a complex dev environment.
Unfortunately issues like this don't get a lot of attention. I think it's because, once setup, most programmers breathe a sigh of relief and get to work. Alas, all of the programmers that come later (and sometimes even you yourself) will have to go through that same pain. Wouldn't it be better to ease the pain of others?
That's what this post is about.
Consider installing Tomcat in Windows. Pretty simple. And yet there are at least three ways to do it.
It may very well be that the image is maintained using #1 or (hopefully) #2, but I shouldn't have to recapitulate the effort of the sysadmin and/or architect every time I set up a workstation.
The appliance approach has other serious benefits. Virtualization lets programmers play with an entire multi-tiered system, and to treat the machine images themselves as deliverable artifacts.
Finally, this mode of development lends itself to deployment to virtualized infrastructures, like Amazon's EC2 (and it's inevitable competitors).
Some questions arise. For example, how much of the app do you bundle with the image? How do you patch the image OS without wasting lots of space (e.g. you want to avoid deploying a new 500MB image every time you patch one little utility) ? How do you develop using images (e.g. do you share the local filesystem to the host OS using samba? Do you force developers to use vi on the image? Or...) Should the image be responsible for source checkout and checkin too?
WRT checkout, I'm guessing no - that falls under the realm of developer tools. However, there is a strong case to be made that developer tools should also be under revision control and perhaps virtualized. Deviations could be tracked as branches. Great way to knowledge-share between programmers. (It's shocking how insular many programmers are about their habits and tools!)
Unfortunately issues like this don't get a lot of attention. I think it's because, once setup, most programmers breathe a sigh of relief and get to work. Alas, all of the programmers that come later (and sometimes even you yourself) will have to go through that same pain. Wouldn't it be better to ease the pain of others?
That's what this post is about.
Consider installing Tomcat in Windows. Pretty simple. And yet there are at least three ways to do it.
- The normal way: install Java, then install Tomcat, then tweak it, the JRE, and the OS as needed.
- As a package: apt-get, or XAMPP add-on (alas, XAMPP still requires seperate Java install), tweak as needed.
- As an appliance: install vmware player, install pre-tweaked Tomcat appliance.
It may very well be that the image is maintained using #1 or (hopefully) #2, but I shouldn't have to recapitulate the effort of the sysadmin and/or architect every time I set up a workstation.
The appliance approach has other serious benefits. Virtualization lets programmers play with an entire multi-tiered system, and to treat the machine images themselves as deliverable artifacts.
Finally, this mode of development lends itself to deployment to virtualized infrastructures, like Amazon's EC2 (and it's inevitable competitors).
Some questions arise. For example, how much of the app do you bundle with the image? How do you patch the image OS without wasting lots of space (e.g. you want to avoid deploying a new 500MB image every time you patch one little utility) ? How do you develop using images (e.g. do you share the local filesystem to the host OS using samba? Do you force developers to use vi on the image? Or...) Should the image be responsible for source checkout and checkin too?
WRT checkout, I'm guessing no - that falls under the realm of developer tools. However, there is a strong case to be made that developer tools should also be under revision control and perhaps virtualized. Deviations could be tracked as branches. Great way to knowledge-share between programmers. (It's shocking how insular many programmers are about their habits and tools!)
No comments:
Post a Comment