Description of the limitation and why it is relevant to address
As a developer I want that the cli does not warm about using registered_name in .toml over the --registered-name flag. In a DTAP (Development, Test, Acceptation, Production) system, this does not work because a single Github/Devops repository is used for publishing to multiple apps.
I think this is relevant for the VIKTOR platform because not all developers work with 1 repo for 1 app as mentioned. As a result, you each time get the extra question when publishing when the answer is always the same.
Submitter proposed design (optional)
Remove the suggested .toml change when publishing. It is already documented in the documentation.
This suggestion has been implemented in the CLI since publishing is often perceived as a difficult step by developers, as well as to create awareness of the possibility to configure the registered_name.
For more experienced developers it may indeed be annoying. As a workaround you could commit something like this:
We think that it would be great if you only have a single application for these different stages of the DTAP flow. You can still have different workspaces, pinned on different versions of the application. Do you think this is indeed a good approach?
Roeland indeed mentioned this to us. A few things that cross my mind with this:
You sometimes have different app variables per DTAP phase. Each version for examples points to another DTAP version of an API we use.
That also means that you manually have to update workspaces to assign a new app version. The UI needs to support bulk updating the version of multiple workspaces then.
Maybe you can introduce special DTAP tags to workspaces then to at least make filtering easier (for example to select workspaces in point 2).
The UI will need an option to cleanup previous versions because now the app is just overwritten
Personally, I donât mind having different apps for DTAP. It keeps things nicely separated without the need for selections in a single apps like which version or app variables.
Hi, I tried the following suggestion (registered_name=â-â) and this does not prevent a warning to occur.
Our workflow consist of a test-app and a production-app. Therefore, assigning an application to a specific repository does not integrate well in the process as there would be a need to modify the registered_name between the test-phase and the production-phase.
Is there a solution currently or something weâve missed ?
We will be introducing development workspaces specific for each app. This means that you no longer need to clear your testing data while switching between apps. This does require you to specify which app you want to âdevelopâ. You can do this in two ways:
specify in configuration file
use the flag --registered-name to start, clear, publish your app. For example viktor-cli start --registered-name test-app
This is a great opportunity. I did not mention it but I find it very useful. Our question is a little different. We have 2 published applications, one for the testing phase and for the production. Itâs based on the same repository with our branching strategy (think âtestâ branch and âproductionâ branch).
Do we need to precise registered_name = âtestâ and registered_name=âproductionâ in both these branches ?
Edit:
There was a concern raised about developping different apps at the same time and the impact persistent storage would have on âstorage compatibilityâ
Do I understand correctly that you publish using a CI/CD pipeline?
In that case I would configure the pipelines in such a way that you publish to the different apps based on some condition. This could indeed be a merge on a specific branch. Alternatively, you could also consider adding a stage/job that you manually trigger to update the production app, whereas you always publish to the test app.
For publishing using a CI/CD pipeline you would use viktor-cli ci-publish NAME where you would replace the NAME variable based on some condition with the name of the test app or the production app.
There was a concern raised about developping different apps at the same time and the impact persistent storage would have on âstorage compatibilityâ
I am not entirely sure what you mean with this. The data of the development workspaces of the two apps are isolated. This also holds for storage. Does that answer your question?
