Thanks Rene !! .
As you mentioned thats exactly our issue how to avoid manual intervention in code management and deployment. We keep the prompts in the project itself , however we are deploying prompts and vxml on Apache, while deploy scxml workflows on tomcat. But we always face issues where multiple developers work and forgot to manual upload in a central repository.
One question : if we go and just use tomcat for everything ( prompt, vxml,scml ) , will the war file we create also contain callflow/workflow files or we have to still maintain those in repository like git separately...I mean concern is that there should be at least one place from where we could pull the latest code and also revert to earlier deployed version if required.
One solution i see is :
1. Code management : Zip the projects completely upload them to git manually as we cannot do so directly from composer.
2. Deployment : Stop bifurcating static content from JSPs/java pages... just use tomcat for everything..the only downside is we might have to restart tomcat even for prompt change....
Please advise ...
------------------------------
ABHINAV GUPTA
Adobe Systems
------------------------------
Original Message:
Sent: 05-15-2020 04:23
From: Rene Wagner
Subject: Composer Project Deployment best practices
Hi Abhinav,
Just my two cents...
1/ I would prefer centralised server, mainly from operational perspective, as keeping the prompts together with code (WAR file) would require code re-deployment with every prompt change
2/ I would say that WAR deployment is easier to maintain and Tomcat can be fine-tuned to server static page almost at the same speed as Apache. Please be aware that implementation of some Composer operations, especially web service requests, relies on Java Server Pages/Java servlets so Tomcat is mandatory here.
3/ Composer is based on Eclipse IDE that supports multiple versioning systems. I prefer git personally but it is your decision at the end. Just be aware that Composer's callflow/workflow files are not fully 'versioning-friendly' from a perspective that it is very easy break structure of the file, so Composer won't be able to open such file. This is mainly due to the fact that workflow/callflow files contains code as well graphical representation including links between blocks and Composer cannot handle situation when one developer replaces block that other developer still uses thus links between blocks get broken. Git gives you possibility to handle such situation during merge operation/conflict but it is not easy to repair these files manually. This is especially an issue if you application is monolithic block.
------------------------------
Rene Wagner
OmniHouse
Original Message:
Sent: 05-14-2020 07:57
From: ABHINAV GUPTA
Subject: Composer Project Deployment best practices
I am looking for best practices to deploy composer projects :
1. Should we deploy prompts in each project or have a centralized apace server for static files .
2. Should we deploy everything as a war file ( both vxml and sxcml ) ..on tomcat or just deploy as static web pages on apache server..
3. How to maintain code repository for callflow and workflow projects when there are multiple developers in team?
#Implementation
------------------------------
ABHINAV GUPTA
Adobe Systems
------------------------------