Environment Package Updates and Application Builder Reports
Does anyone have issues when doing a package install for bringing Dev to Production.
I did a recent update from Dev to Production with some changes on a few modules(4) and couple questionnaires(2) (6 total)
I have spent days going through making sure that the two environments are in fact the same.
The Application Builder reports that i have used were inconsistent and many pages to try to compare.
Is anyone else having this issue?
- Community Thread
- Forum Thread
- RSA Archer
- RSA Archer Suite
Thanks. My comments on your Idea might shed some light on what you are seeing, [DEAD LINK /ideas/4163#comment-36766]https://community.emc.com/ideas/4163#comment-36766
Thanks, however i think you misunderstood my issue. I want Archer to remove the stuff i have removed
For example Lets say i have dashboard that contains 3 iViews: A B and C -
These are currently in Dev and Production
I then make a change to the dashboard in Dev to remove B and C and add a new iView D.
When i package it up and install on prod my dashboard will have A,B,C and D and i have to manually remove B and C - This happens even when i use the Create New and Update and Override Layout.
Similarly if i have permissions set up on iView A that removes a group and adds a new group - all the groups are there and again have to manually remove the permissions i no longer want.
What i am asking for is for Archer to remove these and make everything the same as what is in the package that i have installed.
I do understand and it has potential of being a huge time saver but the nightmares it could create, out ways the benefits.
Lets look at this scenario; permissions was granted to a group in production to a workspace, dashboard or iView. And that change never was done in a lower environments to keep in synch We all know this happens time and time again The take a look from a critical field added in an emergency, etc.
Now a new package is pushed across the environments and the packaging say well this (new) group isn't part of the package I'm going to delete it. Now tons of users lost access and people scramble to find out what happened.
IMHO deletion is a very scary option in regards to installing packages.
With that said one though would be when mapping, is one of the choices; other than mapping to the correct object, not to map is delete. This add could considerable more time in mapping a package but might give the choice to delete or not and to verify it's safe to delete the object
Making a change to production and not updating Dev is basically just poor administration.
Yes i agree that there may be rare times where something needs to be done immediately on Prod that cannot go thru the full dev cycle - however, these "patches" to prod need to be addressed in development or yes you will lose your change after updating dev to prod. Ask any programmer if they make a "patch" to fix an error and don't put that fix in the current release what happens to the fix they made once the customer updates...
My concern is when an Admin is doing everything correctly and updating from a tested Dev environment then putting it in Prod - things need to be double checked and totally retested in Production - Whats the point in having a development and stage environment?
My point is that the mapping and installation process needs to be improved.
I can see both sides to the coin here. I've personally installed packages where it's absolutely saved my behind that it doesn't delete anything (David's scenario) and I've also installed packages where I get nothing but hate mail for a week because it doesn't work/look like UAT did (TUMarkF's scenario).
What if packaging could be enhanced, particularly in the mapping stage, to identify all of these items where there are discrepancies, and ask me how to resolve each one? Options would be Keep Target, Overwrite with Source, or Merge. They could all default to Merge, which is essentially what the platform does now but I would have the option to overwrite or discard if I wanted to. In this regard, I can on an item-by-item basis choose how to handle discrepancies to these items. Back to TUMarkF's scenario of Dashboard iView and perm field updates, I would be able to choose Overwrite with Source for both.
I hope you voted for my "idea" I posted, as this is the idea behind what you are saying - the ability to be presented with all of these items and improving the mapping and installing process.
[DEAD LINK /ideas/4163#comment-36766]https://community.emc.com/ideas/4163#comment-36766
I also believe that the mapping and installing should not be separate steps but combined into one step with the ability to save your progress (as this new mapping may take a bit longer but at least all prep work would be done before the target environment is actually updated...)
Maybe RSA will have a focus group on what admins need/want in this new Mapping/Installing.
It's "nice" to know i am not the only one going through this... (i hate saying that because it's not nice knowing people are going through the frustrations i am going through but at least we are not alone)