Don’t touch systems in mid of projects.

Don’t touch systems in mid of projects.

In my last post “How many Landscapes/Regions/Systems/Environments needed for smooth deployment” I mentioned that we are changing our systems as per second solution.
However that solution is very painful. The thing we learn from that change is “Do not touch your stable systems in mid of projects.

Yes that a great lesson we are learned. We are really going through system change pain. I know if we successfully implement our changes, then system blockage problem will be over. But so far that seems to us a long way to go.

Problem we are facing with change is:
Our all projects are stuck. Why, be because all System and clients are in update mode. So we can do anything.
All QA times are consumed by smoke testing. The whole day we are just doing smoke testing in different, different systems and clients. I suggested my Project Manager, that lets first do all updates and let’s don’t make any build and let’s make all system to be little bit stable. When all dust stable then we can go and do smoke testing and other testing. But my Project Manager is no mood to listen me.
Its all confusion and disorder here. There are some 4/5 builds every day. That’s making hard to track all the changes in those build.
For every builds we are doing smoke test. I think we should stop doing smoke test for every build, until unless when if build have some major changes. Our QA team is so confused. Example, if Team are in mid-off smoke test in T0, and then come emails from PM, that now do smoke test in T1 or T3… and blabla...

Yes I know it’s painful, but I’m very optimistic, that, after all systems became stable, then life would be easy. I hope…