Skip to main content

Configuration Release Management

This is the overall description of how to handle configuration release management within ABB PCP.

Release process overview​

Below you can see the complete flow to release a configuration item, e.g. a component or an installation package. A description of each sub-part (Development, Release & Distribution) can be found further down on this page.

Complete_Process_Flow

Development​

sub_development_releaseFlow

  • Only pull requests that pass build validation will be committed to the protected central repository
    • using build artifacts (not publishing to a feed) at this point.
      • build artifacts do not incur any additional cost for ABB, but items stored in a feed cost per GB used storage.
  • Builds that pass build validation and publish artifacts shall be published as build artifacts
  • All items published to build artifacts shall be signed (see release section for more information)
    • When needed for the intended usage, an ABB release signing certificate shall be used.
    • If it's not possible or needed to use release signing, an ABB internal signing certificate shall be used.

Release​

sub_development_releaseFlow

  • Should look at published artifacts in relevant publications
  • Can be automated to trigger a release flow when artifacts are published/updated
  • Quality gates shall be implemented as defined for the release
    • It is strongly recommended that all packages that are published contain xml-based package description files (or equivalent information)
      • Suggested information to add to the XML-based package description file

        • Name of package

        • Version of package

        • Time and Date of build when the package was published

        • Traceability to build definition and possibly version

        • Traceability to executed build/publish for this package

        • Target OS (Version + name) for package

        • Target HW architecture for package

        • List of components included in a package

          Should contain "closest children" not grandchildren etc. A version of the included subcomponent shall be specified.

        • Including a list of external ”real” 3rd party NuGet from NuGet.org etc.

          A version of the included 3rd party shall be specified.

        • List of dependencies package/version

          Dependencies that this package has. The version of dependencies shall be specified. Not children’s dependencies, only own. These can be found in the child’s description file.

    • The appropriate signing of all executables and binaries for the intended target view (Local, PreRelease, Itemsor Release)

      • packages for local view

        Is the "latest and greatest" and might not have comprehensive testing done. items in this view are expected to be internally signed and are then only allowed to be used internally within ABB.

      • packages for PreRelease and Release view

        Shall be signed as needed for the intended use. The release signed is required for all entities leaving ABB premises. Internal signed items are only allowed to be used internally within ABB. Are allowed to be used for formal testing. Shall have package description information.

    • Controls of the branch that was used for the creation of packages should be checked as per the product CM plan
  • Deploy gates shall be defined for each release and be automated as far as possible
    • E.g. approval of release owner of final release package.
  • A re-build/re-signing might be needed on all binaries and executables.

    • When a re-build is needed for release signing this shall be done on the main/master/release branch on the same tag/label that was used for the initial build.

      E.g., Install Shield to recognize and upgrade a component it needs to have a higher version number, and this can be handled by a specific versioning number schema, where the branch id is part of the versioning number.

Distribution​

sub_distribution_releaseFlow

  • Feeds are used for the distribution of packages
  • Views are used to indicate the maturity of the package
    • Local
      • Signed as per intended usage, no extensive testing done "latest & greatest" published.
      • Examples
        • used to e.g. distribute part of function to other internal entities within ABB
    • PreRelease Signed as needed per intended usage with ABB certificate. Shall have passed all needed tests for intended use
      • Examples are:
        • alfa/beta releases
        • Releases to be used by other ABB organizations
        • Released shall have a quality level that is expected for end delivery for the next consumer with the intention that delivery could go to the end customer.
      • Examples are:
        • Release candidate for the next consumer
        • Final build for release

Q&A​

  • N/A

References​

Owner: Configuration Management Team