Release management of non-trivial WEBCON processes

0

Hi Jarosław,
In my case it's mostly mix of suggestions you've already proposed.
For those tiny touch-ups like adding a column to a report, changing name of path or attribute we're currently doing it mostly manually on dev/test/prod, as it's the fastest way to deliver.

We don't add steps or new fields directly on TEST/PROD though, those require whole path (in theory it's possible to manually override GUID's of those objects, but we don't want to make updates on the database).
Also creating new reports/dashboards on PROD directly might cause new URL's to those objects, and any saved URL's will fail after an update (it's not a big deal, but worth to consider too).

For long running / work heavy features I'm using "Feature flags" concept - creating a new Constant with boolean values, and make them different per dev/test/prod as needed depending of state of the feature.

In terms of gathering all those change requests, we're now developing a separate webcon process, where everybody can send ideas to improve application, and those are approved by application business owner, and there is estimation of time/price required to deliver. Lastly given that we currently have access to Import endpoint through webcon API our end goal would be to automate that process to remove those manual corrections on PROD environment. With the CD pipeline automatically deploying packages to TEST/PROD developers can focus on creating features rather than importing/exporting multiple times.

The thing that webcon lacks from my point of view, or what we haven't solved yet is 'multiple branches' or 'parallel' work on different features by different people.
Feature flags allow it partially, but don't solve everything.

The case with interconnected applications, i'd say the best way is to think about them as separate applications even though they are on the same platform and it's easy to tangle them together, and try to avoid using constants/objects/anything from picker from one in another, rather create some Interfaces between, which will have a 'no change guarantee', or would require informing others when they are being changed. Those interfaces for me are Webcon Data Source views, or UDF's which were introduced in latest version.

Hi Jarosław,

this is one of the draw backs when choosing a low code platform. You can’t easily deploy/test specific features developed in a „branch“. Ok, if these features rely/impact each other then you have a problem regardless of the platform.

As a partner with products/ process templates build on WEBCON BPS. We can’t rely on constants for storing environment specific information. Therefore one of my first ideas was to create a „configuration dictionary“. Which can store values for each dev/test/prod. This has evolved to configure specific features and which values can also be overwritten on business entity level. This is our approach to handle new/alpha features. Of course, they need to be independent from each other. Otherwise it won’t work.


In the end though it all boils down to a feature freeze and telling the employees that they need to test or they won’t get their new feature. After all, they requested it.

Best regards,
Daniel