11
Views
1
Comments
Seeking advice on managing parallel squad workflows in OutSystems deployment

Dear members,

I am a developer on the Modernization Squad, tasked with migrating our Java legacy to OutSystems. Recently, another squad, the Improvement Squad, joined our efforts. They focus on developing new features for the OutSystems application.

To provide context, we develop all features in the Development (DSV) environment. Once completed, we initiate the Jenkins pipeline. Our objective is to move the application from DSV to the Testing (TST) environment, with a subsequent transition to the Staging (HMG) environment after client validation in TST. Therefore, the pipeline progression is from DSV to TST to HMG.

During the client validation phase in TST, we maintain the deployment process but await client approval. Upon approval, Jenkins proceeds with deployment to HMG. In case of client rejection, we halt the deployment, address the issues, and restart the process.

However, a challenge arises due to parallel work between our squads. When deploying modernization features, the current work of the Improvement Squad is also included since OutSystems lacks branching capabilities. Consequently, the client may encounter incomplete improvement features during validation, leading to rejection of the HMG deployment. This situation necessitates alignment between the Improvement and Modernization Squads, which can be challenging to achieve.

You may suggest employing feature toggles to manage this issue. However, any indication of another squad's feature in the deployment, such as a new role or entity, risks client rejection.

Do any of you have insights on how to address this scenario effectively?

2019-01-07 16-04-16
Siya
 
MVP

Indeed, feature toggles are the primary strategy available to manage concurrent development challenges in the OutSystems environment, despite the platform's limitations with branching. However, this approach has its limits, particularly when it comes to hiding new roles or entities, which feature toggles cannot conceal. This exposure carries the risk of client rejection during validations if incomplete features are perceived. To address this, it's crucial to ensure that only fully developed features are visible during the testing phase. Enhancing coordination on release schedules and feature readiness between squads could also help mitigate the risk of client rejection by preventing premature exposure of new functionalities.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.