App Studio Development & Deployment Guide

Development

In building out a search application, App Studio developers use an IDE (Intellij, eclipse, VS Code), maven for server-side dependency management and its integrated jetty plugin, NPM for client-side dependency management and Java 1.8 JDK.

We first will clone the repository of our project on our local system. From there we make additions and edits to the code which we then commit to the repo.

In order to test our changes in real time, we use the integrated maven jetty plugin to serve up our local application at http://localhost:8080 where we can see most changes made to the code in real time.

Environment / Profile management

For each environment, we build out a profile to overlay specific parameters to this environment. See the section entitled ‘Package the web application for different runtime environments - build profiles’ here for more details: https://dev.twigkit.net/docs/Getting_started/Installation/Building_from_source/?q=profile

Example command: mvn clean jetty:run -Dtwigkit.profile=profileName

In App Studio apps, we can have different profiles for each environment (Dev, QA and Prod) as well as local development. These profiles contain configuration files that should overwrite the files with the corresponding names and directory locations in the main resources directory.

Setting up a profile

Following are the files you may want to specify for a given environment in each profile:

message.service.fusion.conf – This config file is responsible for the configuration of the way we send signals to the Fusion endpoint. The important property here is query-profile, which we should ensure points to the query profile that manages the main collection to which we want to send signals. I.e. – if we specify a query profile that points to the myCollection collection, App Studio will send signals to the myCollection_signals collection (if it does exist).

platforms.fusion.fusion.conf – This is our base Fusion platform configuration file. It manages all the configuration settings that are common amongst each Fusion platform. These settings are inherited by any config file in the platforms.fusion directory, as this file has the same name as the directory it resides in.

platforms.fusion.data.conf – This is our configuration file for the main platform, by default. The only required parameter is the query-profile to send these queries to. This is included in the profiles as during the course of development, there were some differences across environments in the name of this collection, so we set them individually for each environment.

The important property to note here is query-profile which tells App Studio which query profile to fire search requests against.

security.kerberos.conf – This is an example of a security configuration file. In this case, the file in which Kerberos security is configured. The parameters set here are referenced in our configuration of resources/spring-security.xml when the app is loaded. The main parameters to understand are service-principal and keytab-location. The service principal should be the one used when creating the keytab file. The keytab location is the location in which the keytab resides on the server that App Studio is running.

security.security.conf – The function of this file is to set general parameters related to security. The type parameter should be the type of security your app should use (kerberos, spring_security, saml etc..). The password parameter is the key that is used when hashing passwords using twigcrypt utility. It is to be used in combination with a ‘secret seed’ in order to generate the hash.

services.api.fusion.conf – This is the main file in which the connection to the Fusion API is configured. ­The host, port and protocol values are all given independently. The credentials given are that of a service account that has POST rights to enable the sending of signals to Fusion.

logback.xml – In this file, we can add additional <logger> tags to print out additional logging on specific classes in the webapps or local logs. The main logging comes from the root package twigkit.

Packaging and Deployment

Packaging

To deploy our code to the server, we build and package the source code and dependencies into a WAR file using maven.

Command: mvn clean package

In order to package the app with the proper connection details and other configuration settings for the particular environment (dev, prod, etc..) see the section above re the profile parameter.

Command: mvn clean package -Dtwigkit.profile=profileName

You can watch the logs for any compilation errors. If it’s not already, rename the resulting WAR file to ROOT.war.

Deployment

Create a new App Studio context in Fusion

Prerequisites:
1. Fusion is installed
2. A Fusion App is created

Execute the following command using a user who has Admin rights:

curl -v -u admin:password -H 'Content-type: application/json' -X POST 'http://localhost:8764/api/apollo/apps/my-fusion-app-name/webapps' -d '{"id": "myasapp","name": "My AS App","contextPath": "/"}'

Upload the WAR to the Fusion webapps service

curl -v -u admin:password -H 'Content-type: application/zip' -X PUT 'http://localhost:8764/api/apollo/apps/my-fusion-app-name/webapps/myasapp/war' --data-binary @ROOT.war

This will put the WAR file into the Fusion blob store, and tell the Webapps service that this is the file that should be started in the specified context.