Component Packaging for easy software deployment
Release Engineer helps you with Component Packaging
Component packaging is the lowest level of assembling together the artifacts to be used in your software release. Release Engineer starts your software deployment definition at the Component level. I view components as a set of binaries, .exes and .dlls or ,jars that make up a runnable part of an application. Components can consume other components. For example, the date time component can consume the logging component.
A well architected component will avoid circular component dependencies, even if the dependencies are removed by several layers. Circular component dependencies will cause headaches in the build and in the deployment process. Make a new component if you run into circular dependencies that way it can be reused correctly. You want see a component hierarchy that has all the relationships going in one direction.
Components can have unique logic defined for performing the installation of that single component. For example, a Component could be a WebSphere Server. You may want to build a software deployment that checks to see if WebSphere is installed, and if it is not, install it before going to the next step. Release Engineer allows the use of Ansible Galaxy Roles for defining the low level logic of a common component such as WebSphere. Release Engineer will automatically download the Galaxy Roles upon start-up with pre-defined reusable components that includes the Galaxy Roles logic.
Release Engineer automates as much of the Component definitions as possible and allows you to share Components across ‘domains’ or diverse teams. By sharing components, errors are minimized and your software deployments are much more reproducible. Alternatively you can restrict who sees a Component allowing only particular ‘domains’ to reuse a single Component. Components are added to an ‘Application’ to assemble an entire application package.