partial-build-deploy

Partial deployment

Table of Contents

• Usage
• Partial build & assembly
  • Partial build
  • Partial assembly
• Partial deploy
• Official Documentation
• Try out
  • Deploy directly from directory, via mtad.yaml
  • Assemble MTA archive via mtad.yaml and deploy
  • Build only specific MTA modules defined in the mta.yaml file and deploy them
    • Building a single independent module
    • Buiding several independent modules
    • Buiding a module with build dependencies
  • Dependency validations

Partial deployment is a feature allowing fine control over which parts of the MTA are getting processed by the SAP Cloud Deployment service and which not. One is able to select only certain module(s) and/or resource(s) for deployment. The SAP Cloud Deployment service takes care to orchestrate the deployment only for the selected parts and skips the rest.

Warning

All descriptor validations and dependency cheks on the processed modules are always executed. If the MTA archive is invalid or e.g. an module has a missing dependency (i.e. service instance which should be bound to but does not exist), deployment fails.

Usage

To use feature, pass one of the following environment variablest to the cf deploy or cf bg-deploy commands

-m <module name>	Deploy only the module with the specified name. Note: It can be used multiple times.
--all-modules	Deploy all modules.
-r <resource name>	Deploy only the resource with the specified name Note:It can be used multiple times.
--all-resources	Deploy all resources.ß

Partial build & assembly

Only selected moduels would be built and included in the MTA archive. This optimizes built & assembly time, the archive size and respectfully upload & processing time in the SAP Cloud Deployment service.

Partial build

If you only maintain a design time descriptor, the mta.yaml file, for your project or your module should be built before it can be deployed using the partial deployment commands, you can use the auxiliary commands of the Cloud MTA archive builder to prepare the required artifacts: the modules build results and the deployment descriptor, the mtad.yaml file.

You can find a few tips about usage of the Cloud MTA Builder commands for the partial build in the "Build only specific MTA modules defined in the mta.yaml file and deploy them" section below.

Partial assembly

If staring from mtad.yaml, the cf deploy command is capable of assembling an MTA archive just before deployment. The list of modules passed to the (bg-)deploy command is used to select which would be included in the assembled archive.

Note	the modules path argument has to be maintained for assembly to work. All selected modules should have such pointing to properly build module bits.

Partial deploy

In the current directory you’ll find example cf app payload with the following structure:

• development descriptor: mta.yaml

• deployment descriptor: mtad.yaml

Official Documentation

• SAP Help Portal: Multitarget Application Commands for the Cloud Foundry Environment

Try out

Deploy directly from directory, via mtad.yaml

In the current directory, run cf deploy -m module-b -r service-2. This will automatically assemble an MTA archive and deploy it

$ cf deploy -m module-b -r service-2
Deploying multi-target app archive */mta-examples/hello-world.mtar in org ******** / space ******** as **** ...
Uploading 1 files...
  */mta-examples/hello-world.mtar
OK
...
No deployed MTA detected - this is initial deployment
Processing service "service-2"...
Creating service "service-2" from MTA resource "service-2"...
Creating application "module-b" from MTA module "module-b"...
Uploading application "module-b"...
Scaling application "module-b" to "1" instances...
Staging application "module-b"...
Application "module-b" staged
Starting application "module-b"..
Application "module-b" started and available at "******-*-module-b.cfapps.sap.hana.ondemand.com"
Skipping deletion of services, because the command line option "--delete-services" is not specified.
Process finished.

Assemble MTA archive via mtad.yaml and deploy

First use mbt assemble to create the *.mtar and than deploy it with cf deploy.

Note	This approach is less efficient, as all modules are included in the MTA archive and uploaded to the SAP Cloud Deployment service. Regardless that only the selected ones are processed.

$$ mbt assemble
  INFO assembling the MTA project...
  INFO copying the MTA content...
  INFO generating the metadata...
  INFO generating the MTA archive...
  INFO the MTA archive generated at: /Users/i076083/git/mta_examples/partial-build-deploy/mta_archives/hello-world_1.0.0.mtar
  INFO cleaning temporary files...
$ cf deploy mta_archives/hello-world_1.0.0.mtar -m module-c -r service-3
  ...

Build only specific MTA modules defined in the mta.yaml file and deploy them

Note

Since partial deploymnet requires that all the modules' and resources' dependencies are resolved, we recommend you first build and deploy the complete MTA project (using the mbt build command to create the MTA archive (mtar) file and the cf deploy command to deploy it) and then build and deploy only the changing modules.

The command for building specific modules using the Cloud MTA Builder Tool is:

`mbt module-build -m=<list of modules to build> [options]`

Note

We recommend you to always apply -g option that generates also the deployment descriptor, the mtad.yaml file. The path property for the selected deployable modules in this mtad.yaml will point to the build results of these modules, so you will be able to immediately run the partial deployment command as described in the "Deploy directly from directory, via mtad.yaml" section.

In the examples below we demonstrate how to use the partial build command in different use cases. These examples are based on the project straucture described above and this mta.yaml file.

Building a single independent module

$ mbt module-build -m module-b -g

Buiding several independent modules

$ mbt module-build -m module-b,module-c -g

Buiding a module with build dependencies

Build dependencies are defined via the requires property of the build-parameters section in the mta.yaml file. For more information, read here.

In the sample project, module-a depends on modules module-b and module-c.

You can build the module-a module with all its dependencies using the following command:

$ mbt module-build -m module-a -a -g

The module-b and module-c modules will be built before the tool builds the module-a module.

If you change now the module-b module and would like to re-build and re-deploy the module-a module, use the following command:

$ mbt module-build -m module-a,module-b -g

The tool will build the specified modules only in the correct order.

For the complete information about the Cloud MTA Build Tools partial build options, read here

Once you have your modules built and the mtad.yaml file generated, you can use the partial deployment command as described in the "Deploy directly from directory, via mtad.yaml" section.

Dependency validations

Warning

When selecting an MTA module/resource for processing, make sure it’s dependencies are also selected or are already existing.

E.g. If in a clean environment, only a module is selected, without the services it depends on - deployment would fail

$ cf undeploy hello-world --delete-services -f
...
Process finished.

$ cf mtas
Getting multi-target apps in org ******** / space ******** as ********...
OK
mta id           version

$ cf deploy ./ -m module-b
Creating application "module-b" from MTA module "module-b"...
Error creating or updating application "module-b": Could not bind application "module-b" to service "service-2": 404 Not Found: Service service-2 not found.

$ cf deploy ./ -r service-2 -f
Creating service "service-2" from MTA resource "service-2"...
...
Process finished.

$ cf deploy ./ -m module-b
...
Application "module-b" started and available at "******-*-module-b.cfapps.sap.hana.ondemand.com"
...
Process finished.

Note	If you expect to redeploy MTA modules/resources multiple times e.g. when doing minor adjustments to them - it may make sense to do a full deployment once and later only update the modules/resources you want.