4 Replies Latest reply on Feb 21, 2014 11:41 AM by Joe Piotrowski

    How can i do Application Release Management in bladelogic

    Francois FURSTOSS



      In BSA 8.3SP2 i d'like to have an ARM process with the package.


      Here you have an exemple:

      • A package has been created with a DEV role (DEV server can be targetted)
      • user with role DEV can promote the package to QA environment (the the package will not be modify by role DEV, only role QA)
      • user with role QA cannot modify the package only the properties/parameters value of the job (can only target QA server)
      • package in QA environment has benne tested -> promote to production environment
      • a user with role PROD can now deploy the package.


      My difficult is how to promote package, i have some ideas:

      • external script which update AclPolicy
      • use new specific JOB properties (named environment)


      If it is easy to manage rights (role) on server, i would like to know if someone has install a similar process in BladeLogic (with the package).

        • 1. Re: How can i do Application Release Management in bladelogic
          John Landells

          Hi Francois,


          The traditional way of doing this is via ACL Templates, using the "Replace" option to set new ACL's on the objects.  This can certainly be done via a script, but you might like to try working with the process manually to start with.


          The process would be something like this:


          • DEV role creates the package, with their default ACL Template
          • Once the package is ready for QA, someone in the DEV role applies an ACL Template called something like "Promote to QA", which opens up the object to the QA role, and makes it read only to DEV
          • Someone from the QA role can now choose to either apply a "Release to PROD" or "Demote to DEV" ACL Template, depending on the outcome of their testing and/or your internal processes.
          • If it's now released to PROD, then the PROD role will have the rights to deploy the package to production and other roles will have either read only or perhaps even no rights to the relevant objects


          If I was doing this myself, I would consider using a folder structure - something like Dev, QA and Prod, and have write access to the QA folder for people in DEV, so that they can move packages there before applying the ACL Template, and a similar construct for Prod.  This will keep the packages physically separate.


          If you find that this solution is working, you can still look at writing a simple NSH script to do it for you and in doing so (and through the use of an execution override) you could even tighten down the ACL's further.


          Does that help?


          God bless,


          1 of 1 people found this helpful
          • 2. Re: How can i do Application Release Management in bladelogic
            Francois FURSTOSS

            Hello Jhon, thanks for your answer.


            Usually i work with ACl Policy so i forget using ACL Template functionality.

            Your process seems very interesting.

            This means that when i want to promote from DEV to QA, i just have to move to the QA directory (package + job if needed), then replace hte Acl Template permission on the top of the directory QA (so i'm really sure that all objetcs under the QA directory have the same rights).


            I prefer to create small scripts (promoteToQA for exemple)  because i don't want user have to manage rights.

            • 3. Re: How can i do Application Release Management in bladelogic
              Bill Robinson

              i've seen it done where the promotion happens as another role, where that role only has acl modify on the objects - dev does something to say something needs to be promoted, and then the promoter gets it to QA so they can deploy it, then the same to prod.  once the pkg is out of dev, no write/modify access to the object for anyone other than the qa promoters.