Managing Multiple Concurrent Delivery Teams

Your Appian project team will likely consist of multiple designers and your program may have multiple independent project teams. Concurrent delivery would be trivial if everyone worked on completely isolated changes. However, strong Appian programs take advantage of reusability, like Records, that should be shared broadly across the platform. You'll also likely want to reuse common objects (like utility rules) across multiple applications. Changes to database schemas and external systems also need to be managed.

Unlike custom code development, Appian does not use branching/merging. Whether designers are working in a shared development environment or in different development environments, you'll need to coordinate between them to avoid the common pitfalls of concurrent delivery:

• Overwriting another designer's changes to an object.
• Changing common components without warning.
• Deploying partially complete work for a different application/release.

For all concurrent delivery scenarios, maintain comprehensive test coverage, including regression testing, to validate all existing and new features. Automated test coverage will significantly reduce effort and risk.

Single Application Release

You have one team working in a shared development environment on one application and one release schedule at a time.

• Be mindful in how you plan your sprint, in case dependencies exist between stories. If common rules are needed to support multiple stories, ensure those are worked on first to remove impediments.
• Be mindful of the Object Overwrite Prevention notifications, and do not override anyone’s lock on an object without proper coordination. If you do happen to get overwritten, you will get a notification that the object version is out of date and you will want to merge your changes accordingly.
• Minimize conflicts by splitting rules into sub-rules, process models into sub-processes, etc. These objects can be modified independently.
• Restrict deployment duties to a smaller group.
  • Team members without deployment responsibilities should never make changes to higher environments.
• Minimize common deployment errors by ensuring all deployment packages are reviewed by multiple people.

Overlapping Releases of the Same Application

You have one team wrapping up work on the next release and a second team getting started on a future release.

• Appian recommends against this because the amount of overlapping changes is usually very high. Projects that follow an agile approach and release frequently should not need concurrent delivery efforts.
• Special Case: To make an urgent fix to production while development on the next release is in progress follow the instructions to deploy an application hotfix.

Multiple Independent Applications

You have different teams working on releases for different applications at the same time. There may be objects shared between applications and the releases may be deployed at different times.

• Use the general guidance provided above for working with a single application release. Coordination will need to be more formal between teams than coordination within a single team.
  • A more robust object tracker that categorizes modified objects by application can be used to manage changes and aid in patch deployment in this scenario.
• Isolate objectsusing applications.
  • Assign a clear owner for every application (including shared applications).
  • Coordinate with the owner to request changes to that application.
  • Use a different naming prefix and folder hierarchy for objects in each application to quickly indicate ownership.
  • Restrict editor/admin access to avoid accidental changes.
  • Create documentation to manage dependencies between applications.
• Utilize a Staging Environment to test deployments and catch dependency issues before they reach Production
• For shared object applications, leverage packages for deployments.
  • Leveraging packages minimizes the risk of half-baked code being pushed to the higher environment by development teams using shared objects. For example, if Team A is ready to deploy Shared Object A, but Team B is making changes to Shared Object B, deploying the full Shared Object Application will result in unfinished code being promoted to the higher environment. Instead, if Team A is only using Shared Object A, they should push only that object.
• For objects shared between applications (like Records), deploy partial changes but hide them from end-users until they are ready.
  • Shared objects should be included in a shared application which has a clearly defined owner.
  • Use highly-restrictive object security role maps to hide new record types, reports, actions, and news events.
  • Use feature toggles to defer new rule or process model behaviors, or to hide changes to existing objects and interfaces.
    • A feature toggle can be created with a boolean constant/rule that's used at key points in the application to enable a new feature.
    • For example: Two independent releases both need to add a view to a record type. Add them both and deploy, but design a feature toggle in the visibility expression to hide them from end-users until each application is formally released.
• Deploy updates frequently to a Test environment.
  • As work is completed and objects reach a stable state, they should be frequently deployed to a test environment and peer reviewed.
  • For very large, complex teams, daily deployments can be useful for successful regression.
• Apply governance.
  • Hold teams to similar best practices, schedules, and guidelines for development and deployments.
  • Hold recurring “Scrum of Scrums” meetings to keep teams on the same page.
  • Align regularly on sprint schedules, upgrade schedules, and any other activities that may interfere with regular deployments.
  • Ensure security is properly configured on shared objects, and establish a process for allowing updates. This can be an access request / approvals process, creating a core team that manages shared object updates, assigning special access for shared objects to only team leads from the individual teams, etc.

Appian recommends using a shared development environment. This approach:

• Has lower infrastructure cost and complexity.
• Avoids the need to merge objects from different environments.

If you are forced to use separate development environments (for contractual reasons or otherwise), there are different considerations:

• Although objects can be modified in parallel on different environments, you still need to minimize the amount of overlap to make merging easier.
  • For example: Performing hotfixes in a separate environment is recommended because the amount of overlap is typically very small.
• Coordinate and plan merge activities as part of a program-wide release schedule.
• Avoid creating objects with the same name or purpose in different environments.
  • Use unique naming prefixes or coordinate shared object creation between teams.
• Merge to a consolidated test environment as frequently as possible to minimize risk.
• Use Compare and Deploy to to identify conflicts between object versions.