I have just taken over as the main Appian administrator for our organization and

I have just taken over as the main Appian administrator for our organization and am thinking there should be a "better way" to how we are handling environment migration. Does anyone have any best-practice advice for migrating from dev->test->production? The concerns I have are mainly about keeping track of what packages have effected what processes as well as backing out changes. Is it better to always move an entire Application and therefore update the single application definition over time? Should we have application fixes (minor versions) and therefore falling back to a previous version would require a lot of hunting to previous packages.

Any advice is greatly appreciated!
---John...

OriginalPostID-63953

OriginalPostID-63953

  Discussion posts and replies are publicly visible

  • I think it it better to deploy application packages as a whole. One thing to pay attention to is: Constants and groups are overwritten. So if you have modified them on production you migth break something when deploying. So you should exclude them from the package if the meant to be changed.

    For fixing smaller things I have a single temporary application that is only used for that.

    What do you mean with changes? New requirements / change requests / user stories or changes in a model or rule?
  • Changes as in bug fixes mainly, but could include other items. We do not currently change constants in production, so that's not too much of a concern for us. My main concern is really identifying what consists a process (application) and how to rebuild it or migrate it to another environment en masse.
  • How is your organization set up? We have a team of project managers that manage our internal improvement projects. The resulting change requests are developed by a small team of process modellers who are also responsible for deployment, testing and so on. Administration is done by our IT dept. but only on an operational level regarding keeping Appian running, technical interfaces to other systems etc.

    Keeping track of what belongs to an app can be hard as there are always common reused things and items that are not recognized by dependency analysis. Maybe you have an application package that mainly contains the user frontend (pages, navigation) and a hidden maintenance app that cumulates changes and is reset on deployment.
  • We have 3 main groups. The infrastructure group which looks after the servers/platform as well as performs the UAT and Produciton migration of packages. The applications group which performs the L2/L3 troubleshooting and bug fixes. The development group which creates new processes and large-scale changes. We do have a couple sets of "common" elements which are packaged separate from each of the major applications. Each process (or group of processes really) are considered separate applications.