Ignore conflicts with Lifetime API v2

We are trying to build a CI/CD pipeline for a shop with multiple teams that support different sets of apps. Each of these teams support apps with independent lifecycles but may use shared modules across the teams. The frequent issue we have been encountering is that sometimes a team will require a change to a shared producer module and cannot wait to coordinate deployments for all the consumer applications. Most of the time, OutSystems supports this if you're using Lifetime since you can just select "ignore errors" in the validation step and uncheck all the "redeploy consumer" apps before initiating the deployment. The dependency model of OutSystems does support this since if you don't redeploy consumers the undeployed consumers will still reference the old DLL and will not be impacted.

When reviewing the source code of the PIP plugin (outsystems-pipeline) which enables cross-platform CI/CD tool support by connecting to the Lifetime API I noticed it is hardcoded to just give up if there are dependency conflicts. I forked the repo and changed that code to allow conflicts and then not redeploy outdated apps using the available option in Lifetime API v2:

In the above example the value is set to "True" but the issue I am encountering is when I hit this endpoint on a deployment with conflicts and that "RedeployOutdated" value is set to "False." Every time I try to hit this endpoint on a deployment with conflicts with this configuration I either (1) receive a 500 internal server error or (2) a 400 and a message that informs me I cannot start the deployment with providing a reason. The actual response appears to change day by day for some reason.

My question is: has anyone else experienced and/or had to overcome this issue? If there is some workaround, I am open to it as well.

Solution

Hi Grayson,

I checked with our Engineering team and, currently, the LifeTime API doesn't allow you to run deployments that have conflicts, regardless of the value provided to the "RedeployOutdated" parameter (as opposed to what can be done through the UI).

Consequentially, in order to have independent release cycles between different teams by levering CI/CD pipelines, you'll need to mitigate breaking changes in your shared producer modules as much as possible (in this KB entry you can find which changes are considered non-breaking). This will require you to apply changes to shared producers in an incremental way, while ensuring backward-compatibility with affected consumers (e.g. by creating a new API version if the signature is changed to include additional mandatory parameters allowing consumers to switch to the new version over time). 

Factory architecture and governance also play an important role here as well. For instance, if you're applying a domain-driven architecture approach you can have strong-coupling inside of each domain and loose-coupling between domains through clearly defined Domain APIs. Combining this architecture pattern with single-team ownership of each domain, enables independent lifecycles for each domain defined in your architecture.         

Best regards,

Rui Mendes

Thanks Rui, we recently heard back as much from another source which corroborates your response. So even though this is incredibly disappointing, I will be marking your answer as the solution. Thank you for providing helpful documentation to make it work in the meantime, but hopefully OutSystems is working on a better dependency model which will allow us to work in distributed teams using enterprise CI/CD toolsets. 

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