5 Replies Latest reply on Nov 23, 2017 8:44 AM by joetetley

    HEAT Development Project Best Practice/Advice

    DTurner Expert

      Hi Community!


      I am looking for advice regarding HEAT Development Projects and perhaps if anyone has used them, how you went about managing this.

      This is currently my main concern as we haven't used projects before but given the current project I am tasked with, there have been a lot of changes to the non-production system so I emphasised we need to look into this feature further.

      To provide some context, at the moment we are using an unorthodox setup, perhaps wrongly so, where we have Staging, UAT and Prod tenants. Our Staging site is essentially ignored, for lack of a better word, and all the work I am doing is performed on UAT. I have suggested testing this process by migrating the UAT setup onto Staging.


      From what I can see, each transaction details is contained in a transaction set, which can then be assigned to a project. Should these sets be managed separately in some way? At the moment, there is an ever-growing list of transactions.

      What things do not get transferred (have you noticed anything additional not explicitly detailed in any documentation)?

      Did the procedure run smoothly - where there any 'quirks' that required attention post-migration?


      Any advice/tips would be very much appreciated





      EDIT: Thought I should add that we are a Cloud customer.


      EDIT 2: In case anyone happens to be of the same mindset I was, I would recommend the following Ivanti Webinar: [Tech Brief On-Demand Webinar 2017] Cloud Service Manager Configuration Migration Process (formerly HEAT Software)

      Please also see the helpful responses below from AlasdairRobertson & katherinec. Other than that, I would say go into Staging and try it out, I found that to be the best way to learn

        • 1. Re: HEAT Development Project Best Practice/Advice
          AlasdairRobertson ITSMMVPGroup

          Hi Declan


          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.
          2 of 2 people found this helpful
          • 2. Re: HEAT Development Project Best Practice/Advice
            katherinec Apprentice

            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.

            1 of 1 people found this helpful
            • 3. Re: HEAT Development Project Best Practice/Advice
              DTurner Expert

              Thanks for the comments AlasdairRobertson & katherinec - very much appreciated!


              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!

              • 4. Re: HEAT Development Project Best Practice/Advice
                DTurner Expert

                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(?)

                • 5. Re: HEAT Development Project Best Practice/Advice
                  joetetley Apprentice

                  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.

                  2 of 2 people found this helpful