No, that’s not stuttering. That’s SOX (Sarbanes-Oxley), bureaucracy and paperwork getting in the way.
Thursday: Original UAT (user acceptance testing) release date.
-6 AM CST: planned release (noon London)
-7 AM CST: I get into work, late
-9:30 AM CST London gets the password to the UAT box (mstsc)
-Attempts to package (compile code) project fails due to dev/UAT environment inconsistencies.
-Make changes to property files, label new code, submit change request, etc.
-11:00 AM CST: London team leaves, it’s 5:00 PM London time.
-We’re stuck. We can’t do anything because we have no access to the UAT box…AWESOME.
Friday: Pushed UAT release date.
-7 AM CST: planned release (1 London)
-10 AM CST: London team gets new password to UAT box
-Attempts to package success!
-Configuration on application server has not been done, we put in a change request. Again, delays.
-I requested to have developement setup EXACTLY like UAT (should have been that way in the first place).
-11 AM they leave, we’re stuck.
-3 PM CST I stay configure, deploy and test it, DONE. Documentation, DONE. Test Results DONE.
-I must stay to prove everything is in place for UAT.
-8:30 PM CST I leave the office.
Paired Programming? Paired Proving.
Today, Monday: Final UAT release date.
-7AM CST: planned UAT release.
-7:15 AM CST: I get in at, late.
-10 AM CST: Passwords get setup
-Everything works perfectly.
All this hassle for configuration changes and hoops to go through. All the processes are required, but it does make developement to deployment sluggish.
One thought on “Project Re-Re-Released for UAT!”
o snap. ahahah