How does OutSystems enable team collaboration?
Table of contents
Apps developed with OutSystems consist of modules, which makes team collaboration easy, even for development factories with a large number of developers. In a modular system, multiple developers can be working on a single app but because it is composed of modules, they are most likely to work in separate modules. However, if it is necessary, teams can collaborate in the same module.
Modular architecture
With OutSystems, developers create modular application architectures that enable organizations to isolate the areas where developers work. These "multi-module solutions" eliminate many developer or development lifecycle conflicts. Multiple developers can work in separate modules with the confidence that their work will not be affecting others. All versions of applications and modules are stored automatically in a central repository, every time they are published. Relevant application and module milestones can be tagged, version history - including who and when - can be checked and rollback to any prior version can be easily downloaded.
Multiple teams in large organizations
To enable multiple teams in large organizations to collaborate and to reduce the number of development cycle conflicts significantly, OutSystems enables different developers to work in different modules at the same time with:
- Isolation
- Deployment plans
- Staging control
- Federated user management
- Operation audits
- Starter templates
Isolation
With OutSystems, developers create modular application architectures that enable organizations to isolate the areas where developers have to work to make a specific application change.
In addition, there are a number of components available to help teams keep their portfolio of applications healthy:
- OutDoc: Generates application documentation and basic architecture diagrams
- Discovery: Helps you assess your entire portfolio's health
IT collaboration in a deployment plan
When multiple teams are working at the usual rapid delivery pace enabled by OutSystems, all eager to push changes to production, sometimes you end up with daily deployment cycles with changes from several different teams.
A shared deployment plan can support these complex deployment scenarios by enabling teams to add their applications and synchronize, in a single operation, the deployment of their changes to another environment.
All deployment operations are governed by the permission levels. Any user with the appropriate privileges can add an application to a plan. Executing the plan, however, requires permissions for all applications in the plan.
Staging control for complex deployment scenarios
As a portfolio grows and the number of applications and modules increases, it is only natural to expect different development and operations lifecycles for applications and modules. If a portfolio has hundreds of applications and modules, it will require more specific control over which versions of the applications and modules are pushed to production. Moreover, perfect visibility of what the impact and timeframe required for the deployment is critical.
OutSystems provides fine-grained control over deployment operations. Typically, teams will push an entire application version between environments with one click. But it is also possible to choose which individual modules to push. This enables someone to quickly push a small hotfix, instead of deploying the full app. In addition, deployment plans are validated to make sure that all dependencies are satisfied and apps are consistent.
Federated user management
OutSystems enables each user to have one role in each team and that role automatically applies to all applications that belong to the team. Adding or removing users and applications to the team is easy.
To support a federated development model, where the central administrators ensure they remain in control while opening the door for each team admin to manage their own teams, there are the concepts of Team and Application Manager. Users with these privileges for an application can manage that application’s privileges for other users.
Similarly, if a user has that permission over a team, the user can add and remove other users to and from the team, without requiring an administrator.
Operation audits
Enterprises often keep information about events that occurred in their systems or networks to help system operators troubleshoot problems, track system usage, record the actions of users, and provide useful data for investigating malicious activity.
OutSystems logs all activity that changes the state of infrastructure, including user management, role management, team management, infrastructure management, and application lifecycle operations. This logging is available for all top level objects, such as users, roles, teams, applications, environments, and infrastructure and helps organizations identify who did which operation, over which object, and when it was done.
Starter templates normalize and bootstrap apps
With the set of templates provided by OutSystems, team members can create new applications that share the same look and set of widgets.They can also be bootstrapped with an initial set of service or API references that not only ensure the overall visual consistency of apps, but also guide them in complying to standard enterprise architecture.
Developers can also find and share templates in the OutSystems Forge, getting help from and helping everyone in the OutSystems Community.
More information about large team collaboration
Additional details about features that enable large team collaboration are available in this article.
Team collaboration in the same module
For developers working in the same module, OutSystems offers everything that is needed to implement a continuous integration development cycle between developers:
- Compare and merge
- Resolve and detect conflicts
- Developer sandboxes
- Version control
- Tagging for deployment
Developers are able to manage versions, releases, deployments and all component dependencies for multiple staging environments from a centralized console. There is no need to install complex tools for configuration, build and version control, nor find the experts to set them up.
Teams can easily view which version is in each environment and can have several choices for automatically deploying or rolling back an application version. If they use the Lifetime Console, they can deploy or rollback a version with a single click:
Compare and merge
The development environment of OutSystems enables developers who work in the same module to merge their work. By default, OutSystems will automatically merge the differences, but the option is there for developers to compare and manually decide what gets merged before publishing.
This image illustrates a situation for comparing and merging work before publishing:
This is the situation. One developer opens version 4 of the module in his development environment and starts developing while a second developer does the same thing with version 4. Both publish their changes. At that point:
- OutSystems determines the changes to be merged based on the version from where both started developing (version 4).
- The modified version is detected so the developer who publishes last can compare and merge.
- The developer compares and checks the changes to be merged.
- The developer merges and publishes.
This is what the visual merge looks like when developers are comparing two different versions:
Resolve conflicts
When developers work in the same module and change the same elements, OutSystems identifies any conflict and helps resolve it by offering a choice of which changes to merge and publish.
This image illustrates a conflict encountered in development.
In this situation, one developer has opened version 4 of the module in their development environment (1) and is developing while another developer is doing the same thing with version 4 in their development environment (2). The first developer then publishes the changes as version 4 but the second developer publishes their changes as version 5 (3). In this scenario:
- OutSystems determines that there are changes to be merged between version 4 and version 5
- The second developer will be able to compare and merge and decide which conflicting changes to keep (4)
Here's an example of a conflict that was detected:
Developer sandboxes
OutSystems provides developers with a private sandbox for their development activities. This makes it possible for several developers to work in the same development server without affecting one another's work.
In a development server, all OutSystems applications have a public area and a private area (sandbox). When a developer is working on a change to an OutSystems application, he is able to deploy changes only to his private area during the develop-test cycle. When the functionality is stable and can be shared with the team, the developer can publish and merge his version of the application with the version in the public area.
Version control
The backbone of all these collaboration capabilities is the built-in version control engine of OutSystems. From the time applications are first created, OutSystems keeps all versions, components, and connectors stored in a central repository transparently whenever someone publishes an application. Users can navigate through versions, see when and who published them, download or roll back to a previous version. During development, this is done automatically, which saves time and work.
This is an example of the version history of a module. Notice it's possible to download or rollback to any previous version with a single click:
Tagging for deployment
With OutSystems, it is possible to take a snapshot of an application and its dependencies, tag it with a version, and then use it for deploying. In this example, the Vacations application has new functionality for submitting half-day vacations, so it is tagged and development continues.
Tagging an application is critical to ensure infrastructure stability and flexibility. Tagging is usually done when the application development is stable or a milestone is reached, allowing for the retrieval of that state of the application and its modules at any time.
Development teams can tag a version of their application each time they reach the end of a sprint. Then, they start a new sprint and continue developing their application. Meanwhile, tagged versions of the applications can be deployed to quality assurance without interrupting the continued development of the application.
