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/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/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/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/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/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