2 of 2 people found this helpful
I would start here: Ivanti SM OpsConsole Guide v2017.2.1 On-Premise with the Opsconsole User guide (P44 on wards really). The core idea is that you push a copy of your production database to staging make any developments/changes service requests and then these can be packaged. these packages are tested in UAT and then can be applied to Production.
The core things that I come across for most customer that do not move are listed below (there are probably more):
- LDAP Settings (this is always done in production)
- Business Calendars/HOPs
- All transaction data stored in an object not marked as a validation object for example incident records. (non transaction data for example would be incident statuses which will be included as part of a package)
Here are my key steps:
- Mostly I would say have a play with it from staging to UAT before you do your new development and get used to the process
- Come up with an organisational approach to naming conventions for field/object names
- Try to avoid 2 people creating projects around the same object at the same time or ou will end up with synchronised changes in packages (these will then not apply in order and potentially cause issues)
- By this for example one person could would in Incident and another in Service Request.
- 2 people could however work on separate Request Offerings simultaneously if they are careful.
1 of 1 people found this helpful
I have been using Projects and Packages quite extensively and had very few issues (I am premise). Definite improvement to the old push mechanism and much quicker. The only small issues I have had are as per Alasdair's list - I think also escalation schedules need manual attention and I can't validate a package that deletes an object but other than that they've been pretty sound.
I keep track of changes recording Project, Package and Transaction Sets involved in each change. There is no 'rollback' facility so it is useful to keep track this way in case you decide to leave a change out of your package or you find you've got into a cul-de-sac somewhere. I am the only administrator and tend to work on one kind of project at a time so don't run into overlap often, but I think you would have to be quite careful if there is more than one person making changes at once. One thing to bear in mind is that when you refresh your stg/uat from production you lose the details of your historical transaction sets.
I refresh STG/UAT from production perhaps every couple quarter. I have STG with no historical transactional data and apply changes and package up on this tenant. UAT has 90 days of data and I apply and test the package on here first. This is useful because you don't have to 'close' a package to apply it to UAT so you can test in chunks as you go and make corrections if necessary. You can reapply packages over and over with additions. When you're finished you close the package and apply on production. You can export the XML metadata of the package to a file so you can record/examine the contents if you need to.
Hope that helps a little.
To update (and bump the thread!), we went with a refresh from UAT -> STG so we are working properly now. Doing so though meant I still didn't test Package deployments .
Does anyone have any insight into Cloud-based solutions at all?
I am fairly sure it is advised to request package pushes through Ivanti Support but there does appear to be an Export/Import option on the AdminUI. Honestly, little bit scared to deploy this either way but I suppose I will have to at some point and the earlier the better, plus it would be on a non-prod tenant so should be fine.
If anything breaks, you never heard from me!
Finally managed to look into Development Packages and fortunately enough, not as scary as I imagined
The problem I have now is levelling the projects/packages so that STG and UAT are the same (I think due to the unorthodox refresh this messed things up slightly)
I think this is manageable but now I have the tedious job to go through the package as it wasn't done properly before - all a learning curve I suppose!
Does anyone have any advice as to common errors/warnings? The errors seem to be due to existing data - can this overwrite instead or is that too large of a risk(?)
2 of 2 people found this helpful
I've been using Projects and Packages in the cloud for some time now. My advice would be:
* to plan out any data changes that are needed in advance for items that aren't metadata and included in the transaction sets e.g. if you need to build rules around data that won't be pulled across then you have to either do this in Prod first before your refresh or make sure you have updated this in the environment before you apply a package to it.
* I always start by refreshing STG from PRD and work on STG. That way UAT is still available for testing any bugs or issues that may arise whilst you are working on your project in STG.
* Version name your project and your package. Check the Transaction counts between your project and package.
* I keep a log of what I've done on each object and put the transaction id next to it. This helps me unpick if something goes wrong but is also useful as a history if your trying to remember how you did something e.g. how you wrote a particular expression.
* Once your package on STG is complete, refresh UAT from PRD before applying the package. That way you are also testing the process of the promotion of the package to your PRD environment.
* Check the security history on UAT to make sure your users have logged in and testing before agreeing to promote to PRD.