The Deployment Automation Manager consists of two tools used for:
Although the tools are best used in conjunction, they can be used independently as well.
The Automated Versioning Manager is a tool that helps manage Appian applications and database DDL files in a version control system. Given an Appian application ZIP file, the Automated Versioning Manager performs the following actions:
The goal of this tool is to facilitate the adoption and usage of a version control system to perform configuration management of the Appian applications and database DDL files.
With the Automated Import Manager, users can automatically deploy applications and patch contents (either applications from Appian OR packages generated from the Automated Versioning Manager) to any environment. Users will have three options for deployment: the tool can either deploy from the tool’s user interface in one click, trigger the deployment from an external CI tool or deploy from the command line.
The Automated Import Manager automates the process of inspecting the application, executing DDL scripts, updating CDTs, republishing the appropriate datastores, and importing the application.
For more information, please visit: https://community.appian.com/w/the-appian-playbook/198/deployment-automation
v2.5.11 uses a newer version of Flyway (v6.5.5). See the release notes here: https://community.appian.com/w/the-appian-playbook/198/deployment-automation#release-notes
I think the Flyway Community Edition only supports database versions that are less than five years old.
facing issue with Automated Import (v2.5.11) for database deployment :
Status: Failed. Current step: Inspecting Application. Error message: Flyway Enterprise Edition or Oracle upgrade required: Oracle 12.1 is no longer supported by Flyway Community Edition, but still supported by Flyway Enterprise Edition..
It's encrypted as per TLS when communicating with the environment, but I don't think it's encrypted in-place.
Is there a way to encrypt the password stored in the import-manager.properties? This violates are security compliance.
Couple of critical enhancements which are needed on these tools . If any one has any work around for the below, please feel free to share.
1. Token based authentication. Storing password and user ID in property file is not best solution in terms of security.
2. Multiple parallel deployments. At a time two deployments is not possible. This will a blocker when 7-8 team as going to deploy.
3. Getting the detail logs at the end of import. There is a manual step to log in to tempo to get the details log. If we are doing CICD, then why again a manual step. The tool should share detailed log.
Yes we were creating a new branch from the master. We had used -branch_name.
Were you checking out the branch outside of the tool? It should be able to switch branches if you use the "-branch_name" option.
I guess we have found what was wrong.
When a new branch is created from master the versioning configuration was getting copied which was referring to master branch. After changing the configuration in the new branch to refer the new branch, we have not seen this issue occurring.
We have not tried with GitHub. It work in local machine. If we can get some details on when and why the rename operation happens maybe we can troubleshoot.
Do you know if the same thing works on a GitHub account?
© 2021 Appian. All rights reserved.