From
cyreneforum.com:
Looks to me that they can...
People don't realize that this can take a while to go through and there are a lot of moving parts that can and do change on the fly and cause all kinds of problems. Also it depends on the resources available, the people, the budget, the tools, methodologies, philosophies, cycles, automation, dba's availablity, password rotations, tool upgrades, current development, future development, programs, projects, support work, server patches, server moves, upgrades, retirements, disaster recovery work, network changes, upgrades, database patching, moves, upgrades, backups, conversions, application patches, upgrades, outages, working with vendors to resolve issues can sometimes take forever, training, vacations, conferences, LOA, for any number of reasons, and on and on and on. All of this takes time. The smaller the company, the smaller the team the more multi-tasking the less time to focus on one thing, the longer something can take, etc.
The process can go something like this...
First they get a gazillion support cases from all the moronic end users who think if they overload the support system it will somehow go faster
so they have to sort through all of those and separate the wheat from the chaff.
Then they have to have a meeting to discuss the support cases.
Then they have to decide what support cases are a priority.
Then they have to schedule things to be worked on and decide what kind of release it is going to in and when that release is going to take place.
Then they have to research the problem.
Then they have to develop a solution.
Then they have to do a code review.
If problem during code review the developer goes back to the drawing board and fixes then goes back to code review for approval.
Then they have to check their code in and put it into development environment.
Then they have to do unit testing.
If there is a problem during unit testing developer will need to fix it.
If it tests fine the tester creates test evidence.
Then they have to create a change request and submit it for review and approval.
Then they have to wait for release meeting to have it reviewed and approved by the release manager.
If release manager finds a problem with change request, they send it back to developer to fix and resubmit with fixes.
Then the release manager approves it along with all the other things they are reviewing.
Then the release operations has to prioritize it for the next install/build cycle.
Then release operations puts it into the test/uat environment.
If release operations has a problem trying to install/build, they send it back to developer to fix the problem. When it gets fixed it goes back for release operations install.
If installed correctly with no issues then they have it tested.
If there is a defect discovered in testing the tester creates a defect and sends the change request back to the developer to figure out what the problem was.
Developer figures out what the problem was, cancels original change request and creates a new one for the new defect fix, closes out the defect and submits the defect fix change request for approval at the next release meeting and it starts the install process all over again.
If testing was good and no defect then it is approved and staged for production release.
Production day comes along and they deploy it.
Then they do prod verification/smoke test.
Then start the process all over again.
Or something like.
Like I wrote, depending on a lot of things there are many different ways to do it. But it can look like that, and it can be quick if there is not a lot of bureaucracy, or take a lot of time to get through that process, if it makes it through at all!
Note, there are a lot of steps I question if they are doing at all, like code review, testing, etc. but that is another story