Skip to main content
Version: 10.2.4

Build SDLC with ODF

SDLC principles​

Team SDLC​

Delivery Pod SDLC looks as follows.

Key practices for delivery Pods include:

  • Release build from tagged code
  • Auto-deploy build from Git
  • Reuse components shared as JARs
  • Avoid any changes in Control Tower
  • Redeploy any change or bugfix
  • Have access only to required Git repositories

Multi-team SDLC​

ODF is designed for adoption by large companies where WorkFusion rolls SAA programs. In regards to teams structure, SAA offers to form two types of groups:

  • Feature Pods
  • Delivery Pods

ODF allows to organize effective shared code ownership for such a structure of teams. It is critical to well establish and follow processes as it should be aligned with crucial requirements:

  • Security. None of organization-internal business solution code can be shared outside of the organization.
  • Contribution. It may be beneficial for the organization if WorkFusion will accept some company's component or ODF code feature. Thus, the company may save efforts on new ODF version migration, simplify or speed-up its own implementation .
  • Permissions management. Internal repositories should be accessed by proper organization's groups.
  • Easy start and adoption. ODF must be made possible to learn and try BEFORE it is deployed to the company's VCS or Repository.

Multi-team code ownership is as follows.

How to start new odf-based project​

Below are general steps that the Project's technical team is suggested to follow once they adopt ODF fist time in their organization.

Prepare server environment​

LEAD DEVELOPER | ARCHITECT | IT OPERATIONS

  • Patch Control Tower with ODF JAR
  • Roll out deployment automation ODF REST service into Control Tower
  • Put WorkFusion dependencies (from https://repository.workfusion.com) into the organization's local repository
  • Create organization's local VCS (Git) repositories:
    • shareable with other organization's teams (for Feature Pod)
    • non-shareable (for Delivery Pods)
  • Set up access for developers
  • Agree and document naming conventions for repositories and modules for all teams to follow

Project setup​

LEAD DEVELOPER | ARCHITECT

  • Generate initial Java project structure from the quickstart archetype (provided by ODF in repository)
  • Generate all RPA modules (one per automated business application), other shareable components using the quickstart-module archetype (provided by ODF in the repository)
  • End up with Maven Project with multiple Maven Modules
  • Verify the build is successful and can be deployed to server Control Tower
  • Push the project into the organization's local Git

Project team implements solution​

ALL DEVELOPERS

  • Each developer checks out the project from the organization's local Git
  • Project Lead Developers educate the team on where to put the shareable with other organization's teams or non-shareable code

Release activities​

RELEASE ENGINEER

  • Create a tag in Git
  • Build a deployable package
  • Install all modules into the organization's local repository (Nexus)
  • Deploy using the deployment automation ODF REST service into server Control Tower

Fix bug in QA, UAT, and PROD​

ALL DEVELOPERS | RELEASE ENGINEER

  • Roll out local project version out of the Git tag of the build where a bug has been found
  • Fix
  • Create a tag in Git and follow the rest of release activities from the step above