Multi-team shared modules
Problem definition
Assume you are a Solution Architect of a large enterprise and your automation teams want to know how to design projects based on the WorkFusion platform more efficiently. Naturally, you would expect the following features from a proper design:
A new project is easy to start. Implementing project-specific code should take a few minutes, rather than days or even weeks.
The code structure is well-layered and intuitive. Developers literally enjoy their advance. It is also easy to introduce new people to the project codebase.
Automation parts repeatable across projects are reused by different teams. For sure, WorkFusion as a platform and ODF 2 as a framework already provide a set of technical components that accelerate automation. However, to further advance the reusability idea, there should be a chance to leverage the code parts developed for a specific enterprise by Team A by Teams B, C, D, and so on.
The code is covered with automated unit and integration tests, and CI/CD processes are set up for large implementations so that teams are comfortable introducing any changes to the codebase.
Important practices mentioned above and delivery success depend on how well those processes are established. The article focuses on #3.
note
Essentially, the code-reusability design proposed for Enterprise is defined as follows: automation of separate applications, systems, and models is well decomposed, with the code stored in separate version control repositories. Then, it's easy to share them between teams for reusing and extending.
Multi-team SDLC principles within Enterprise
Maven and Version Control allow organizing effective shared code ownership for a structure with multiple teams. It is critical to establish well and follow processes as they align with crucial requirements:
Security. None of the organization-internal business solution code can be shared outside of the organization.
Contribution. It may benefit the organization if WorkFusion accepts some company's components or the ODF code feature. Thus, the company may save efforts on a new ODF version migration, simplify and speed up its own implementation.
Permission management. Internal repositories should be accessed by proper organization groups.
Easy start and adoption. ODF must be made possible to learn and try before deploying it to the company's VCS or repository.
The multi-team code ownership looks as follows.
Understand ODF 2 project's moving pieces infrastructure
ODF 2 is a toolset that consists of several Java libraries, Maven plugins, and Java archetypes. To access the resources, go to the Nexus repositories at repository.workfusion.com. You can download the same set of libraries as an archive and easily drop them into the on-premises Nexus. You can also configure your IDE to use the Nexus repository as an Archetype repository or drop Archetype JARs into the local Maven cache. After that, use ODF 2 Archetypes to create a new project.
Once a new version of ODF 2 is out, download the new archive and add its contents to the on-prem Nexus. Archetypes must be put into a repository designated as an Archetype repository. Put Maven plugins into a repository designated for Maven plugins accordingly. Then, you can use the new version in your code.
Design for multi-team code-reusability
Principles of standard Maven project decomposition
ODF 2 is designed to represent a single Digital Worker as a separate project. "Project" in this case means a Maven project surrounded with a set of all required infrastructure—a Git repository on a server, a CI build job, a Nexus repository to hold built artifacts, and quality control tools (at least test reports and metrics on CI). A build made by CI from a source code in a Git repository is a single source of truth about the project state, meaning no "works on my machine" excuses and no deployments to common environments from developers' PCs.
A Maven project is not atomic. It is divided into separate modules, each responsible for different tasks where one module represents a bundle, and the other ones refer to BCBs with Bot Tasks. Parts of code generic enough to be used by multiple BCBs can be extracted to their own modules inside the project.
Now, if some part of code grows to the point it can be used by different Digital Workers—for example, it contains some common utility or a data model—it gets its own project and infrastructure. Other projects use it as Maven dependency. From that moment, changes to this library can easily break things for other teams using it. Take special care to maintain its integrity and usefulness and put separate effort into API design and versioning.