Posts
1150
Comments
891
Trackbacks
1
What makes code easily deployable?

In a previous post, I asserted that excellent code is easily deployable.  What might that mean specifically?

It depends, of course.  But, let’s try an example.

Separation of concerns is a basic principle that means (paraphrasing) “Don’t try to do too much s$%t at once.”  For instance, if you are working on your UI/Presentation Layer, don’t embed business logic and/or data access logic within it.  An obvious example is to not put ADO.NET code in the code behind of a web forms page.  This makes it harder to test the code (in any sense of ‘test’ that isn’t an end-to-end integration test).  It is painful to only be able to discover that your business logic doesn’t work by firing up IE and watching some interaction with the page fail.  It is, unfortunately, often unavoidable, but life is full of trials and tribulations.

However, there is a way in which separation of concerns can lead to difficulties in deployment.  One of the standard blah blah dictums of software development is that the greatest cost involves maintenance, and deployment is a maintenance cost (especially if there are multiple environments to which code is deployed…if you’ve worked in places where the number of deploy targets is greater than single digits, you really know what I mean).

Suppose you have an application that needs to be scheduled by some means (whether Windows Task Scheduler, SQL Agent Jobs, 3rd party scheduling tools, etc.).  Suppose your application is such that it is parameter based, and so there are multiple instances that need to be configured for scheduling.

I’ve already touched in the previous point on how to minimize difficulties by not doing stupid crap (technical phrase) with configuration, but there are issues beyond that.

From a development standpoint, it would seem really bad to embed the multiple parameters inside of the application.  E.g., it seems much better to have single scheduled instances like “myapp.exe ‘task1’”, “myapp.exe ‘task2’”, “myapp.exe ‘task3’”, “myapp.exe ‘task4’” as opposed to having an app that has one scheduled instance “myApp.exe” within which you handle tasks 1 through 4 coded within it (and for the nit-pickers like me, just accept that you can’t do a myApp1.exe, myApp2.exe, etc.).  You should cringe at the thought, since you know that you’ll end up cramming tasks 5-74 into the one executable once you go down that path.

Except….

One key rule of software development (which I have yet to think of a catchy name for) is that you have to know the entire life-cycle.  If you are in an environment that has no deployment issues, none of this matters, but in most real-world situations, there are some.  Besides the number of environments involved, you often have to cross teams for deployments, where the DEV team knows next to nothing about the deployment issues specifically, and the deployment team(s) know next to nothing about what an executable does specifically.

In some such cases, where the maintenance cost of deploying the software exceeds the development cost of not separating concerns, you should violate the principle of separation of concerns.

Beyond deployment comes troubleshooting.  Any scheduling tool worth talking about will have some ability to log what happens when a scheduled executable runs.  But different tools do this differently, and knowing the how the production scheduling tool handles logging is crucial here, especially when developing the executable in the first place. 

It’s easy to (roughly) formalize this into something like this: if ((cost of separating concerns in executable) > ((cost of deployment when separating) + (cost of troubleshooting when separating)) then don’t separate concerns in executable.

In fact, if you know that you can lessen the cost of deployment and troubleshooting by not separating concerns in development, you should do that, even though it is painful as a developer to do it.

The difficulty comes about in determining what the various costs are.  There is rarely/never an exact way to determine this.  The variables involved in the troubleshooting process are many.  If you use EntLib or log4net, you can log things to the EventViewer or to SQL or to SMTP or to your Mom.  Well, when something goes wrong, it’s an at least 85% chance that the developers will have to be called in to fix production issues.  Do the developers have access to the EventViewer?  Probably not.  Read-only access to Production SQL?  Maybe.  And so on and so forth.

The upshot is that when you do software development, you have to keep in mind how your code is going to be deployed, and how it is going to be troubleshot (is that a word?), and if it turns out that by eliminating separate components that are deployed and troubleshot, you end up also eliminating separation of concerns, then you should do so.

Alt.NET people (including myself) like to talk about maintainability, but sometimes, the maintainability for the developer is only one part of the equation.  What is the maintainability for the deployment team and/or the production support team?  In any real-world project, all of these factors have to be considered.

posted on Monday, November 10, 2008 8:12 PM Print
Comments
No comments posted yet.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 3 and 4 and type the answer here: