4 Replies Latest reply on Nov 3, 2017 1:50 AM by nspeed

    How do you document changes?

    nspeed Apprentice

      I would just like to know how you go about changes in systems with development and testing environments

      eg. Ivanti Service Manager



      • one CI Enterprise Application: Ivanti Service Management
      • create change with above CI
      • create a task for staging --> document develpment
      • create a task for uat --> document testing
      • release date  --> status to implemented
      • PIR
      • close



      • additional to CI Enterprise Application - System: Ivanti SM stg, Ivanti SM uat, Ivanti SM prod
      • create change with CI Ivanti SM stg
      • when closed --> create/copy change with CI Ivanti SM uat
      • when closed --> create/copy change with CI Ivanti SM prod
      • PIR
      • close


      C) something else?

        • 1. Re: How do you document changes?
          Jonathan.Schmidt SupportEmployee

          I'm not sure I understand your question or use case.  Can you clarify what you are wanting the community to comment on?

          • 2. Re: How do you document changes?
            nspeed Apprentice


            Maybe it is easier to stick with what I think would work best …




            Name: Ivanti Type: Enterprise Application


            Name: Ivanti-stg1 Type: Server


            Name: Ivanti-uat1 Type: Server


            Name: Ivanti-prod1 Type: Server






            Change Form (simple):


            Requested by: Tom Status: in testing


            Team: IT


            Asset: Ivanti








            In the above setup I have on Enterprise Application and one server for each environment. (Do you have it setup like this?).



            In order to keep track of where a change is I could link the CI (eg. If in development I also link the staging Server Ivanti-stg1). Could be forgotten. Another way would be to use more status à in staging, in testing and ready for production.



            As everyone of you has at least development and production environment I just want to know how you keep track of your changes and find them if needed. At the moment we use Redmine for tracking changes but only for one Application which is rather simple.


            • 3. Re: How do you document changes?
              wynnb Specialist

              nspeed, are you asking about how to track changes to the Ivanti Service Manager application? If so, I only create a change record for what I deploy to production, and only the prod instance of the application is a CI. I created a change template for these, which auto fills some fields and links the CIs (app and server). We use the "ChangesTested" check box to indicate that we've run the update through STG and UAT, so we don't bother with tasks related to those environments - though there's nothing wrong with doing that if that's what your organization requires.


              Really, it all depends on what your org needs. In our case, the decision was that we mostly care only about changes to prod. The exception is server OS patching - in those cases we create change records when we patch servers in each of the environments. I added fields to the Server and Virtual Server CI Types to indicate which environment group each is in, so for example when we create the CR to patch Dev servers it automatically links all server CIs in that environment to the CR.

              1 of 1 people found this helpful
              • 4. Re: How do you document changes?
                nspeed Apprentice

                Thanks for your ideas.


                The requirement is to
                introduce change management, from there onwards I define. So that is why I am
                asking because you lot may have already tried a couple of things. So it could
                look like this:

                CI: Ivanti --> for all software changes plus flag when
                testing is done

                CI: Ivanti Server --> for any changes to the server (windows update,
                more memory, …)

                If something does not work
                the analyst has to know this and list all the changes from Ivanti and then from
                the Ivanti Server(s).