3 Replies Latest reply on Apr 22, 2019 9:48 AM by iiliev

    Package versioning

    xian_ Enthusiast

      I'm looking for recommendations on handling package versioning.


      We're developing custom content for our customer and release the code from time to time as packages. Individual objects (workflows, actions, ...) are versioned but we'd like to differentiate different releases on package level. What is your best practice?

        • 1. Re: Package versioning
          iiliev Champion
          Community WarriorsVMware Employees

          How do you store the individual objects and how do you build the package?


          A possible approach would be store the individual objects in an SCM system (like Git) as plain XML files, and have a continuous build pipeline that builds the package on each commit. In this case, you can mark the produced package file with some unique marker, for example the build number from your pipeline, or the timestamp when the package is produced.

          • 2. Re: Package versioning
            xian_ Enthusiast

            At the moment everything is manual, using only the vRO java GUI. When we feel ready, we push the Export package button

            I know this is very basic... I thought of adding a version number on the file name, but a metadata would be better. I can see only Global and User tags on the GUI.


            Wrt. SCM I tried CloudClient but we have not started using it to export content to Git. We also found vRO extension for Visual Studio Code but have could not get a copy yet.


            Continuous build would be utilizing Maven, right?


            We also tried LCM to export-import content to Git but our appliance crashed recently due to an unexpected storage failure.

            • 3. Re: Package versioning
              iiliev Champion
              Community WarriorsVMware Employees

              Yes, for continuous builds we provide a Maven plug-in that can assemble a vRO package out of various content elements (workflows, actions, etc.) stored as XML files.


              Most of the vRO plug-ins, at least those distributed together with vRO appliance, use this Maven plug-in to produce a package (containing plug-in specific content) every time the plug-in is built.