This blog post is part 4 of a series of blogs on how to develop full-stack To-Do application in SAP Web IDE Full-Stack.

Before reading this blog please make sure that you have read, understood and implemented part 0, part 1, part 2 and part 3 of this series.

Let’s Get Started!

In the last 3 parts of this series (part1, part2 and part3) we’ve created our full-stack app, ran it and tested it locally on SAP Cloud Platform Neo environment.

In this blog post we will show how to deploy our app to SAP Cloud Platform, Cloud Foundry environment, in a single and simple command.

In part 0, we introduced you the MTA concept and explained how it works. After reading and implementing this part you will understand what happens behind the scenes after you build and deploy your MTA app to Cloud Foundry.

Build and Create MTA Archive (MTAR)

Now we need to build our MTA app to create an MTAR file.
What is the MTA Archive (MTAR) file?
An MTAR file contains all the source-code, assets and relevant resources of the app, ready for deployment (Java uses a similar concept called WAR).

Before building the MTA we must do a minor change to one of our files in the ui module, the xs-app.json.
This file contains some routing and destination details of apps running on Cloud Foundry (it’s basically the neo-app.json of Cloud Foundry).

• Double click the xs-app.json file located in the ui folder.
• In the editor tab change the welcomeFile property value from “/ui/test/flpSandbox.html” to “/ui/index.html”.
  This property specifies the path to the executable html file that the runtime environment is looking for.

In order to create the MTAR file, follow these steps:

1. Right-click the todo project and select Build:
2. Now SAP Web IDE will build your entire project, create the MTAR file and put it in mta_archives folder which should be created as a separated folder in your workspace:
3. The naming convention is: <YOUR_MTA_APP_NAME>_<YOUR_MTA_APP_VERSION>.mtar
   the name and version are taken from the mta.yaml.

The nice thing about the MTAR is that all you need to do is to create this file and deploy it to your Cloud Foundry space. Then the MTA build-pack will parse the mta.yaml, use the service-broker to create all the relevant services, deploy your modules one by one as applications or services and finally connect them to each other.
In addition, it allows you to manage your app life-cycle in one place, using the
cf mta command line interface (CLI) but this part will not be covered in this blog.

Deploy the MTAR

1. Right-click the MTAR file that you just created under the mta_archives folder and choose Deploy > Deploy to Cloud Foundry: 

   

2. Select your Cloud Foundry API Endpoint, Organization and Space to which you want to deploy and click Deploy:
3. SAP Web IDE will extract the MTAR, parse your mta.yaml file, build and deploy all the modules inside it (db, service and ui) one after another.
   In addition it will create all the relevant service-instances via the service-broker.
   Notice that this operation may take several minutes to complete.
4. Upon successful deployment you will see a successful message in the upper notification and in the console.

Deployment Troubleshooting

• When deploying to a Cloud Foundry Organization you need to make sure that all relevant services are available in the org.
• If you’re deploying to your CF-Trial environment you must make sure that you have enough resources.
  If you don’t, open SAP Cloud Platform Cockpit > Cloud Foundry Trial > Applications.
  Then stop all the running applications except for the di-builder app:

Run your deployed app

After our app has been deployed successfully to Cloud Foundry we are ready to test it:

• Go to SAP Cloud Platform Cockpit and open the CF space to which you deployed your app.
• Go to Applications and search for ui because that’s how we named our ui module and then click on ui from the search results:
• Click on the URL endpoint located under the ui application to run it.
• You should see the same app that you saw in SAP Web IDE:

Best Practices

• Use versions –
  • MTA provides you the ability to use a version for your app.
  • Giving your app a version is extremely important especially if you develop enterprise-ready apps.
  • I recommend to use a different version every time you redeploy your app to Cloud Foundry.
  • Your app will have only one active version at a time so if some unexpected issues or errors occur in your current running version, you can always rollback to an older version easily, fix the bugs and deploy a new version.
  • Version must be incremental for example: if your current running version is 1.0 then your next version should be greater (e.g. 1.1 or 2.0).
  • The number of the next version can be determined by you. I personally like to use the following logic (assuming the current running version is 1.0):
    • If the change is minor – next version will be 1.0.1
    • If the change is a new feature – next version will be 1.1
    • If this is a new release – next version will be 2.0
  • Make sure that your versions are synced with your Git repository in order to have one source of truth for each one of your versions. I personally love to use git tags for that but you can also use git branch (which I think is not scaled when you have a lot of versions 🙂 )
• Use Git  – Don’t compromise and say “I will do it later”. I recommend to use Git from the first time you build your project skeleton. Git will make sure all your code is synced with other team members. Also, Git is recommended even when you develop your app on your own because Git is much more than just collaboration tool.
• Micro-services – Cloud Foundry and MTA provide you the ability to split one monolith app into micro-services. If for example you notice that your OData service becomes very big, consider to split it into multiple OData services that will be consumed by your ui module via multiple data sources.

There are a lot of other best practices regarding module dependencies, CI/CD, etc, but they will be covered in a separate blog post.