Upgrade Procedures
-
I’ve started at new job recently and am amazed that there are no work flow or project plans when it comes to upgrading applications. My biggest concern is that no else in the IT dept is notified when these upgrades are happening. The app leads take it upon themselves to backup everything up and perform the upgrade right in production and only alert other IT staff when something goes wrong. Usually in that case they need help in rolling back. If everything actually goes according to plan they might send out an email after the fact letting everyone know.
I’ve proposed first off any upgrade should be reviewed by the entire IT staff to make sure the new changes won’t impact anyone else or another application(no matter how big or small the upgrade). I’ve also stressed testing in a test environment first…in fact everyone has been looking at me kind of crazy like because I must sound like a broken record asking them to PLEASE test first. I’ve even been reduced to begging lately!! I’d also like to see the users participating in the testing which isn’t happening yet. I don’t believe a member of the IT staff can test app functionality by themselves since they aren’t the ones using the software on a daily basis. Anyway, I guess something is finally sinking in because management is putting together a work flow process plan to define the steps need to be taken for upgrades or even new installs.
I’m kind of curious to see how other company’s handle upgrades - do you follow a specific project plan that’s the same across the board or does it vary from app to app? Does the project plan need to be approved by a change control board first? What are some of the protocols we should make sure that we include in our plans? When a company doesn't have a project manager- who handles this issues?
Thanks!
-
Nature's little warning signs:
"I’d also like to see the users participating in the testing which isn’t happening yet"
Sounds like a "fun" environment...
I have this saying: "Methodologies are crutches for people who don't know what they are doing."
Yes, there is a double entendre there, but I am usually referring to the worst interpretation. That is, if you don't know what you are doing, how is a methodology going to make things better? When you do really know what you are doing, the methods become fluid: you pick and choose as appropriate for the situation, as there is no instruction set that works in all situations.
You may be in a truly wacky, yet-- these days-- common place, and people can be running around creating havoc at every turn. Yet you should first be sure the disease is worse than the cure. So take time to be sure that problems that spring up in application releases/implementations are having a serious negative effect. Then if so...
In a place where things are dorked up and applications are not safely deployed (regardless of there being a methodology or not), they are dorked up because fundamentally the organization doesn't know what it's doing.
So putting elaborate schemes/protocols/steps in place to solve that problem, doesn't really solve the underlying problem. And it will only become more time consuming/expensive in the long run.
So, to get to the point and give you advice you might use:
Go slow and simple. First, (for example) only seek to get a test/predeployment environment (that matches production configuration) in place, and see if you can get everyone to commit to doing a predeployment test installation there before they install in production.
Then see if they actually follow through on that commitment.
(You might not get that far, you may only be successful in getting a test deployment environment set up without anyone else buying in to it, and then you may have to get them to start using it one at a time.)
Only then, one at a time, work on instituting (in whatever appropriate order):
Bringing in users to test apps
Requiring a backout plan for any implementation
Scheduling
Walkthroughs
etc.
Be patient. Or, on the otherhand, you can always start keeping an eye out for a new job.
-
You are not alone. How big is your company and how many people in the IT department? In my company, we have Oracle, SQL Server, UNIX, AS400 and Window NT. We don't have any UNIX administrator, Oracle DBA, SQL Server DBA, AS400 system admin. I am a SQL Server developer, I have to do all the DBA works, put the patches in SQL Server, backup and restore the database, actually it is kind of fun that I learn a lot, except if I do anything wrong, there is no one to ask and I am stuck. I consider it as a "Challenge". The same as Oracle and UNIX, AS400. So you should look at this way, you learn a lot more than many people, it is a challenge everyday and it makes your life more interesting, unless you want to do the same thing day in and day out.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply