today I'm going to write about a situation every sysadmin has already encountered. The sysadmin gets a new version of some type of software and should install it on a server. After some hours of trying he calls the developer and tells him he's not getting the application to start. The first answer all of us get: "But it is running on my PC." Let the discussion start. ;)
In my opinion it mostly a problem of proper communication. I have also seen (not only once) different types of development environments (mostly Windows) and production/test/... environments (be it Linux, AIX, HP-UX, ...). This could also be a reason for problems, but this is enough for an other topic. So let's come back to the communication.
As communication always two-sided, so is this problem. There can be different sources:
- The admin has changed a default value of a configuration.
- The developer has changed some classes and now needs other permissions or files.
- The admin has installed an update and the application is installed on this test system.
- The developer uses a new library which is not installed on the server.
There can be a lot more other reasons why software fails, but I think you get the idea. Most of these supposed problems can easily be solved by proper communication. When the admin updates a system (be it security patches, os service packs, ...), just write a short e-mail to the users of the system and explain them in short words what you have done and what might be affected by the update. When a developer changes something in the code, keep a changelog. But as a developer do me a favour and do not mail the sysadmin the complete changelog. When it is to long or there are to many terms related to the business logic or how you changed some algorithm to get some more performance, he won't read it. The changes might also be interesting for the sysadmin, but mostly he will not have the time to read it all and get the parts interesting for him. I know developers do not have unlimited time, but for them it is much easier to find the parts affecting the sysadmin, because they (hopefully ;))understand the complete changelog.
In a perfect world we would have a change management which includes development and system administration, but as this will not always be present, just take the short track and write an e-mail, use the phone or do a short(!!!) meeting when anyone knows about changes, which could affect the release. Some people will now starting rolling their eyes and ask themselves who is not doing so already. It's sad but true there are a lot of people out there.
This way your releases will run a lot smoother and every side gets more understanding for the other side which will positively affect other parts of your daily work.