Re: taking deployment/operations considerations into account

Another property that is often overlooked, especially in early versions of a software company's product line, is ease of upgrading the software.  The default assumption, again, is that the user has full control of the environment, and that the software can be taken down at any time for an indefinite length of time in order to perform manual and perhaps quite involved tasks.  The other end of the spectrum is a product that has an automated upgrade installer that performs all the necessary tasks (hopefully not too large a number of tasks in any case) and requires a very short amount of downtime, or a product that can update itself while continuing to run, if so configured (I am not fond of Windows Automated Updates, but then I am not fond of anything about Windows).

Al


----- Original Message ----
> From: Al Chou <hotfusionman-/[email protected]>
> To: [email protected]
> Sent: Saturday, May 3, 2008 5:45:01 AM
> Subject: Re: [pragprog] taking deployment/operations considerations into account
> 
> I like the direction this thread has taken.  Sadly, despite the fact that the 
> developers where I work spend a considerable amount of time many days each week 
> involved in customer support for their own components, I haven't generally seen 
> the product getting better in terms of the deployment properties we've seen 
> discussed here, even though I've repeatedly logged feature requests / bug 
> reports on the subject, explicitly describing the properties/requirements both 
> at the high level that I started this thread with and in more detail.  So it's 
> not clear that eating one's own dog food necessarily makes one want to improve 
> it.  Perhaps our developers aren't spending enough time doing support in the way 
> Gordon advocates.
> 
> That said, I have to admit there is a centralized management feature in the next 
> major release, though there will still need to be work on areas like 
> standardizing the filenames of log files so that one doesn't have to read 
> through the entire listing of the logs directory to find the logfile for the 
> component of interest.  It's also not clear whether the centralized management 
> feature will give access to those logs or whether one will still need to be able 
> to log on to the machine in order to view logfiles.
> 
> Granted there are other pressures that have kept the centralized management 
> feature from becoming a priority in previous releases (like new features that 
> end users rather than ops folks at our customers have clamored for), but some of 
> the smaller properties of our components could have been made better without an 
> overarching initiative/mandate from product management, and that is my main 
> complaint about the involvement of developers in support tasks not having had 
> much effect on the product's usability from the ops standpoint.  Perhaps, as 
> with learning another (natural) language, full immersion is required to truly 
> learn.
> 
> 
> Al
> 
> ----- Original Message ----
> > From: 
> > To: [email protected]
> > Sent: Friday, May 2, 2008 11:51:35 PM
> > Subject: RE: [pragprog] taking deployment/operations considerations into 
> account
> > 
> > I've always been involved in supporting what I write, it comes with the
> > territory.
> > Usually not first line support, but second and third line with more often
> > than not direct feedback to and from users.
> > 
> > XML files are meant to be interpreted by machines, not human beings.
> > If they are to be changed by users one should provide a user interface for
> > them to do so, not expect them to edit the files by hand unless maybe
> > they're extremely simple (in which case usually a simple properties file
> > will suffice just as well.
> > 
> > Jeroen Wenting
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Gordon J Milne
> > Sent: vrijdag 2 mei 2008 12:36
> > To: [email protected]
> > Subject: Re: [pragprog] taking deployment/operations considerations into
> > account
> > 
> > Hear, Hear!
> > 
> > It would do many a development organisation a world of good to ensure 
> > that developers get a six month stint in support or operations on a 
> > semi-regular basis ... every five years. Just to remind them how hard it 
> > can be to use the intellectual output of others.
> > 
> > Modern configuration files (usually based on XML) are a nightmare to 
> > edit successfully and rarely have decent commentary in them to assist in 
> >   understanding the range of permissible values/enumerations.  All too 
> > often an implict familiarity with the relevant class hierarchy is 
> > assumed. This leads to a lot of head scratching by a sysadmin.
> > 
> > I still have problems with log4j, even after 4 years of using it. It 
> > should NOT be this hard.
> > 
> > Regards,
> > 
> > Gordon
> > 
> > Michael T. Nygard wrote:
> > > Al,
> > > 
> > > I share your frustration.
> > > 
> > > I can speak as a developer who has moved into the realm of  
> > > operations---mainly related to web sites and ecommerce.  After that  
> > > move, I became immensely dissatisfied with how poorly most software  
> > > makes the transition to operations.
> > > 
> > > Take configuration files, for example.
> > > 
> > > Some amount of configuration must be under administrator control:  
> > > hostnames, port numbers, and passwords at a minimum.  Usually also  
> > > tuning parameters such as database connection pool sizes.  All these  
> > > parameters must vary from one environment to the next.
> > > 
> > > Yet, these properties are always mingled together with essential  
> > > plumbing of the application.  I use this example from Spring  
> > > configurations in some of my talks:
> > > 
> > > 
> > >     com.mysql.jdbc.Driver> > value>
> > >    
> > name="url">jdbc:mysql://localhost:3306/exp2> > property>
> > >     expdev
> > >     expdev
> > >     10
> > >     40
> > > 
> > > 
> > > This one bit of XML mixes together plumbing (change the  
> > > driverClassName and it breaks completely), environment parameters and  
> > > tuning parameters.
> > > 
> > > Developers should not require administrators to edit XML files by hand  
> > > during deployment.  Worse yet, this file lives inside the codebase, so  
> > > any production properties will have to be replaced by hand after every  
> > > deployment!  That's just begging for errors.
> > > 
> > > These issues, and many others, motivated me to write "Release It!  
> > > Design and Deploy Production-Ready Software".  In it, I talk about  
> > > designing for successful deployments and good operations. I also  
> > > discuss design patterns and antipatterns that can dramatically affect  
> > > how applications survive contact with the real world.
> > > 
> > > (BTW, Spring does provide a handy class called  
> > > org.springframework.beans.factory.config.PropertyOverrideConfigurer  
> > > that can help with the configuration problem above.  Developers have  
> > > to build it into their beans.xml files, but it lets you externalize  
> > > overrides into a simple name=value file that lives under /etc or some  
> > > other place outside the codebase.)
> > > 
> > > Cheers,
> > > -Michael Nygard
> > > 
> > > 
> > > On Apr 28, 2008, at 8:31 AM, Al Chou wrote:
> > > 
> > >> I realize that one's actions/decisions are colored by one's  
> > >> experience, and that not many developers have ever worked in IT  
> > >> deployment/operations, but I'm increasingly frustrated by the fact  
> > >> that our developers do not take ease/consistency of configuration  
> > >> into account when developing our product.  Like Windows (up until  
> > >> Vista), they assume that the administrator of our product owns the  
> > >> machine outright, as well as dependencies such as a SQL Server  
> > >> database that may or may not be installed locally on the machine our  
> > >> software runs on.  These assumptions don't hold up in, for instance,  
> > >> third-party hosting environments (where you can't necessarily log on  
> > >> to the machine via Remote Desktop) or organizations where the  
> > >> separation of responsibilities precludes owning the whole machine  
> > >> (there are plenty of organizations among our customers where the  
> > >> machine/OS-level administrator is not allowed to see the application  
> > >> data, and the application administrator is not
> > >> allowed administrative access to the OS).
> > >>
> > >> I'm wondering how much such issues are taken into account by the  
> > >> individuals on this mailing list?
> > >>
> > >>
> > >> Al
> > >>
> > > 
> > > Michael T. Nygard
> > > [email protected]
> > > http://www.michaelnygard.com/
> > > 
> > > Author of "Release It!"
> > > http://pragmaticprogrammer.com/titles/mnee/index.html