Best Practice - Deployment of Change requests (CRs) to PROD

[matej256]

Hi All,

 

I've searched over the communities as well, but couldn't find answer on my question.

 

The overview is simple and should be used for all companies using Clarity. When some Change request (CR) is developed on DEV, then moved (deployed) to TEST,

approved by company management and testers (in better case ) then deployment to PROD comes.

 

Question is what is the best practice when deploying CRs on PROD? Means we would like to somehow disable users during the down-time of PROD environment (which is in fact up...),

to avoid users login to system. Or something like redirect homepage of Clarity to some page "Under development". Is it somehow easily possible to do?

Or are there any other safe ways? Thanks

 

Matej

[David Morton]

"it depends"

 

--

 

Depends on the "size" of the change, depends on the "nature" of the change, depends on the time it takes to deploy the change, depends on your organisation's IT/business governance, usage patterns (24/7 or 9-5?) ; it all just depends!

 

So a new portlet/query/report/page ; just drop it in ; but changes to a object (stock or and already existing custom object), I'd personally want to do that during some quiet time, but not-necessarily need to lock users out. The only time I think you need to lock users out and provide a under-construction/redirect would be on upgrades (when of course the system would not be available anyway).

[matej256]

Hi Dave,

 

sorry for not providing "depends" info

 

So, it should be deployed during standard hours "9AM - 5PM" during the day when this change may take approx a few hours (1-4)

During this time we can send Clarity users email notification about down-time of Clarity, but we know that many of them are trying to login to Clarity during this time as well ... 

 

We just want to prevent users to log into Clarity during this change....or change home page

 

Thanks

[David Morton]

so "depends on your organisation's IT/business governance" .... if it took 1-4 hours then personally I'd just do it one weekend or overnight.

 

But if you want to lock users out, then just stop the normal app services (and perhaps provide a placeholder page), start an app on an address/port that only you know about and use that to deploy your changes?

 

(just my opinion, other opinions are available ; I don't think you'll find a one-size-fits-all "best practice" though as all scenarios will differ and a rigorous process would be (in my opinion) well over-the-top for a simple portlet deployment (for example) )

[matej256]

Hi Dave,

 

Hmmm, well I thought there exist such a nice easy solution with locking users/showing "under construction" page in Clarity that covers deployment time...

So the response is no, it does not exists

 

Anyway, thanks for your hints.

 

Matej

[Suman Pramanik]

Hi Matej,

 

The best possible way to lock out all the users would be update the user properties to lock status but nothing in the system and needs database update, the other way to do it by changing at the load balancer level and redirecting the traffic to static page with a generic message.

 

Regards

Suman Pramanik

[David Morton]

I'd argue that stopping your app (and using an un-publicised link), or redirecting at intranet (DNS/load-balancer/web-server) level is a lot less intrusive than locking Clarity users on the database (and unlocking the right ones later)....

 

...but perhaps someone from CA could update us on the "under review" state of this idea ; Maintenance Mode Option

[matej256]

Hi Dave,

 

Yes, those 2 things we also got to know from our perspective....

 

Your mentioned idea is great and is exactly what we need...As I could see those functionality needs over the 100 people so quite wondering it exists more than 5 years without any implementation

If implemented, it'll save a lot of time.

 

Thanks Dave for all your points brought up there...

 

Matej

[mike2.2]

Remember that before you lock your users, keep a separate table that holds the current state of the users, so you know who to unlock when the time comes. If you are like us we have a number of existing  locked users that we do not want to unlock accidentally.

[matej256]

Hi Michael,

 

Yes exactly

 

Matej