Application Composition Projects

Every application composition project is basically just a configuration of what and how to deploy together. As every other project type it is stored in a Git repository and therefore all access control and permission settings have to be done in the corresponding Git repository.

After creation, you are presented with the general information on this project including its acronym, the Git provider and the repository group where it is stored. Furthermore, there is a dedicated documentation section which allows you to describe the purpose and functionality of this application.

Besides the Overview section, there is also a Components section that shows you all components used in this application composition project. After creation, you are required to add at least one deployment target to be able to add components. A deployment target is the target to which you want to deploy your application. You can add multiple deployment targets to match your staging concept. Typically, you would add deployment targets for development (DEV), testing (TEST), staging (STAGE) and production (PROD) but you are free to add as many as needed.

Each deployment target can be composed and configure separately to give you the highest flexibility and freedom. This way you can add different components on the different deployment targets or use the same components but different versions of them. You could run a certain version of a component on a PROD deployment target while you test the latest version of the same component on a DEV deployment target.

After adding one or more deployment targets you can start adding components to each deployment target. Usually, you would start adding components to your DEV stage and then prepare the consecutive stages. There you also have a feature to compare two deployment targets and if wanted, choose all component of one deployment target to use them in the other namespace. This creates a duplicate of the previous namespace which you can then edit to match your needs.

In case your applications consists of many components there is also a search bar and filters to quickly find the component you're searching for. Each component can be configured separately for each deployment target of this application project. You will also find binding configurations for all components on a deployment target, so you can adjust things like external URLs, token information or event topics used by the components.

When creating an application you might not have all necessary components already in your component repository. Therefore, you can also add a Planned Component to the application. Planned components are used as placeholders for components that you know you will need, but they need to be built. You can add a description to this planned component so others can see what needs to be built.

This way, you can compose your application only by putting existing capabilities together and add placeholders for the missing parts. These missing parts can then get replaced by the to-be-built components. Each planned component lets you either replace it with an existing component (that may have been added to the repository later) or create a service project.

Service Projects are used whenever you want to implement a business capability on your own. As long as this service project is in development you will have a link to it on the planned component. As soon as the service project is implemented it can get released to the component repository and is from then on available as a component. Now you can replace the planned component with the new component.

After having added all necessary components to the application you have the chance to configure each of them individually for each of the deployment targets and edit the bindings for them in case they make use of bindings. This enables you to set different values for the different deployment targets.

When you're done you only have to click on the "Commit" button and all your changes will be persisted in the Git repository and the GitOps mechanisms get triggered to deploy the application to the corresponding deployment target. Each deployment target has its own "Commit" button to give you the freedom of working on them in parallel without affecting each other.