Integration and data synchronization
  • 25 Sep 2023
  • 7 Minutes to read
  • Dark
    Light

Integration and data synchronization

  • Dark
    Light

Article Summary

The Agile.now Factory application tie together existing tools and scales up the productivity of low-code projects throughout the entire execution process from software design, specification, development, testing to deployment and production. Agile.Now software integrates with several different systems and combines them into one process.

Project management tool

We recommend that you use one of the suggested project management tools alongside Agile.Now Factory. The PM tool defines the steps for automatic publishing and testing thereby enabling automated project workflow and helps us achieve the real DevOps process. Integrating a PM tool such as Azure DevOps or JIRA is mandatory without which we cannot execute Agile.Now Factory.

Integration & unit testing

Integrating a unit testing tool is optional but we highly recommend having them integrated as it forms an integral part of the overall DevOps pipeline. OutSystems provides two different types of Testing frameworks which can be integrated with the Agile.Now Factory application.

  1. Integration and unit tests for the server side:  These unit tests are created using the OutSystems BDD testing framework (ver 1.4.0). You can download the software from OutSystems Forge from here
  2. Integration and unit tests for client side: These unit tests are created using OutSystems BDD Framework for Client Side( Reactive and Mobile applications) and more information about this could be found here

Integration and unit testing ensures the quality of the code developed through OutSystems. One of the advantages of Agile.Now Factory unit testing integration is the intelligent synchronization of unit tests from one environment to another. The tests are also synced for those issues that has been completed and deployed from one environment (for eg: Development) to another (for eg: Testing).

System testing

Automation testing is one of the most important starting point for the application quality assurance. The testing includes several different test case styles such as the unit, integration and use case testing. Performance testing is, of course, part of a comprehensive testing strategy and should be carried out with a separate software. This process is however optional, but we recommend integrating one of the many automation testing tool such as Ghost Inspector or Tosca. Recommendation is write and execute end to end test after deploying to test environment to avoid version issues.

OutSystems Lifetime

The DevOps is based on the OutSystems Lifetime for releases and management and is part of the OutSystems software. Lifetime is the centralized console for managing your OutSystems environments, applications, IT users, and security, covering the full application life cycle from development to deployment. More information about OutSystems lifetime can be found here.

Integration and data synchronization

The table below describes briefly about the data synchronization at various scenarios within the DevOps pipeline and the internal and external tools responsible for this:

Factory data

This details about the data flow that happens between the entities of the OutSystems Lifetime and Agile.Now Factory.

Note: Mandatory

EntityThe owner of the dataSync directionDescription
EnvironmentsOutSystems Lifetimefrom Lifetime to DevOpsThe environments of infrastructure. The lifetime owns the environments and DevOps uses this information to manage deployments.
UsersOutSystems Lifetimefrom Lifetime to DevOpsAll users of infrastructure. The lifetime owns the users and DevOps uses this information to manage authentication. and authorization.
TeamsOutSystems Lifetimefrom Lifetime to DevOpsAll teams of infrastructure. The lifetime owns the teams and DevOps uses this information to manage project structures. The team must include a user in order for it to appear on the DevOps.
Team usersOutSystems Lifetimefrom Lifetime to DevOpsRelation between the team and the user. The lifetime owns the team users and DevOps uses this information to manage authorizations.
RolesOutSystems Lifetimefrom Lifetime to DevOpsRoles that exist in the infrastructure. The lifetime owns the roles and DevOps uses this information to manage authorizations.
Environment accessesDevOpsInternal auto generatedEnvironment accesses that exist in the infrastructure. A data structure that defines users' rights to the environment. Database information is built dynamically when a user logs in.
ApplicationsOutSystems Lifetime / Probefrom Lifetime to DevOpsApplications that exist in the infrastructure. The lifetime owns the applications and DevOps uses this information to manage deployments. Probe adds information from the development environment to make the process as efficient as possible. The application must include a team in order for it to appear on the DevOps.;
ModulesOutSystems Lifetime / Probefrom Lifetime to DevOpsModules that exist in the infrastructure. The lifetime owns the modules and DevOps uses this information to manage deployments. Probe adds information from the development environment to make the process as efficient as possible. The module must include a team in order for it to appear on the DevOps.
SettingsDevOpsinternalSetting of a given infrastructure.

Project data

This details about the data flow that happens between the entities of the project management tool such as JIRA or Azure and the Agile.Now Factory

Note: Mandatory

EntityThe owner of the dataSync directionDescription
ProjectProject management toolfrom PM to DevOpsProject is a collection of issues. Used to coordinate the development of a product and tracking. The project management tool owns the projects and DevOps uses this information to link the projects, teams and issues together.
Project ModulesOutSystems / Project management tool / Factorytwo-wayModules are subsections of a project. Used to group issues within a project into smaller parts. The modules are owned by the OutSystems platform and are synchronized with the project management tool. The project modules must include a team in order for it to appear on the Factory.
Project issue statusesProject management toolfrom PM to DevOpsStatus indicates the issue current place in project's workflow. The project management tool owns the status of the issue, and DevOps uses this information to configure and execute workflows. 
Project issue typesProject management toolfrom PM to DevOpsStores various types of issues such as Epic, Story, Task, Bug. The project management tool owns the issue types, and DevOps uses this information to link the issues.
Project processesDevOpsinternalProcess process indicates the issues project workflow. DevOps owns the processes in the project and the user defines the steps for the process in DevOps.
Project settingsDevOpsinternalConfiguration for statuses which should trigger an action. The DevOps owns the settings.
Project teamsDevOpsinternalRelation between the team and the project. The DevOps owns the project teams. 
Project versionsProject management toolfrom PM to DevOpsVersions represents point in time for a project. Issues can be assigned to a specific version to organize sprints around completing work in that version. The project management tool owns the versions of the project, and DevOps uses this information to define and execute workflows, tests and deployments. 
IssuesProject management tooltwo-way with PM and Factory

Issues are building blocks of a project. An issue could be a story, bug, task or other type. The project management tool owns the issues of the project, and DevOps uses this information to define and execute workflows, tests and deployments. 

The issue must include a Factory project, module, issue type and version in order for it to appear on the Factory.

Issue modulesProject management tooltwo-way with PM and Factory

Stores the relation between issues and modules. Modules can be added in project management tool or Factory.

The issue must include a module in order for it to appear on the Factory.

Issue historyDevOpsInternal auto generatedThe table contains the change history of the issue. Logs are also written for a status change if the issue is manually or automatically moved in the project management tool. 
Issue versionsProject management toolfrom PM to DevOps

Represents relation between issue and version. The project management tool owns the issue versions and DevOps uses this information to define and execute workflows, tests and deployments.

The issue must include a version in order for it to appear on the dashboard. 

Issue test applicationsDevOpsinternalApplication Tests with independent unit tests that are connected with the different issues manually in the PM tool. The application tests are associated with an issue through modules. For eg: A module is added to an issue and necessary application tests are added to that module.

Unit testing data

This details about the data flow that happens between the BDD Test environment integrated from the OutSystems forge and the Agile.Now Factory.

Note: Optional.

EntityThe owner of the dataSync directionDescription
TestsDevOps / Probetwo-way between BDD and DevOpsTests that exist in the infrastructure within BDD. These tests are from the development environment. Sync automatically skips pages named; InternalError, Login, InvalidPermissions, NoPermission, MyInfo, NoTest% (e.g. NoTest_MyDemoPage)
Test executesDevOpsreal timeThis involves with the test execution plan that would test the different test suits from every environment except the production environment
Test resultsDevOpsreal timeResult of execution of tests within the environment where the application tests and unit tests within that application tests were executed.

End-to-end testing data

This details about the data flow that happens between the UI testing environment such as Ghost or Tosca and the Agile.Now Factory.

Note: Optional.


EntityThe owner of the dataSync directionDescription
TestsAutomation testing tooltwo-way between ATT and DevOpsTests that exist in the infrastructure. All of the test are same no matter the environment.
Test executesAutomation testing toolfrom ATT to DevOpsTest execution plans many test from DEV/TES/UAT environments. All of the test under application will be run.

This involves the test execution plan that would test the different test suits from every environment except the production environment. All test will be executed no matter is code is ready or not.
Test resultsAutomation testing toolfrom ATT to DevOpsResult of execution within the environment where the test suite and tests within that suite were executed.
TeamsDevOpsfrom DevOps to ATTSync from DevOps to auto test tool. Structure of teams auto generated from DevOps to Auto Testing Tool
ApplicationsDevOpsfrom DevOps to ATTSync from DevOps to auto test tool. Only application with "Set as home" flag is set as the home application (end user application) when the deployment is completed. 

Was this article helpful?