Home > User Voice > Git repositories

Git repositories
0

I’ve been wondering why Webcon doesn’t support Git integration. It could really help speed up the development of new features in workflows and make it easier to fix any critical bugs quickly. Webcon team — Git support would be a game-changer. Please consider adding it!

MVP

Hi Franek,

I'm sorry to ask this, but did you ask yourself how this would be possible? Since your are mentioning Git I'm assuming that you are a developer and therefore would be able to create a concept how it would be possible.

I read your message thought about it for a short time and dropped the idea. The issue is not the Git integration but that everything that entailed with it.

That's the current situation:
- There are no code files but data rows, which we would commit to git.
- There are multiple dependencies between the data rows.
- Simply everything in WEBCON is build on the integer ids.
- You need to commit all the applications, data sources, connection etc. to git


Issues:
- While you could compare the data rows from one table to another, that's mostly useless because there are dependencies. You would need some kind of visualization to decide, whether something should be merged into a branch without accidently breaking something else.
- Since everything is build on the integers this would need to be refactored to GUIDs. If this change would be applied, I would skip the next major release until everything is fixed.
- What are you doing if you are having workflow instances in steps, which you aren't (yet) available in a commit?
- Adding, removing and readding fields, because of switching branches, which could cause that the same field in the same environment has a different database column which in turn is used somewhere else?
- Security issues with passwords etc.
- Setting up Git

WEBCON BPS is a low code product targeting non developers at end customers , and this change would benefit only a very small percentage of the customers I would guess. The implied risks and costs simply aren't worth the effort.

Feel free to correct me and point out any errors. We would really be glad if there would be something because we, as a partner, are providing the same application to multiple customers and it would be great to have a comparison option between the current deployed version and the new one, before deploying it.

Best regards,
Daniel

In reply to: Daniel Krüger (Cosmo Consult)

Hi Franek,

I'm sorry to ask this, but did you ask yourself how this would be possible? Since your are mentioning Git I'm assuming that you are a developer and therefore would be able to create a concept how it would be possible.

I read your message thought about it for a short time and dropped the idea. The issue is not the Git integration but that everything that entailed with it.

That's the current situation:
- There are no code files but data rows, which we would commit to git.
- There are multiple dependencies between the data rows.
- Simply everything in WEBCON is build on the integer ids.
- You need to commit all the applications, data sources, connection etc. to git


Issues:
- While you could compare the data rows from one table to another, that's mostly useless because there are dependencies. You would need some kind of visualization to decide, whether something should be merged into a branch without accidently breaking something else.
- Since everything is build on the integers this would need to be refactored to GUIDs. If this change would be applied, I would skip the next major release until everything is fixed.
- What are you doing if you are having workflow instances in steps, which you aren't (yet) available in a commit?
- Adding, removing and readding fields, because of switching branches, which could cause that the same field in the same environment has a different database column which in turn is used somewhere else?
- Security issues with passwords etc.
- Setting up Git

WEBCON BPS is a low code product targeting non developers at end customers , and this change would benefit only a very small percentage of the customers I would guess. The implied risks and costs simply aren't worth the effort.

Feel free to correct me and point out any errors. We would really be glad if there would be something because we, as a partner, are providing the same application to multiple customers and it would be great to have a comparison option between the current deployed version and the new one, before deploying it.

Best regards,
Daniel

We have some kind of code due to the import/export mechanism → inside the packages there are XML files that could probably be saved, visualized, and versioned with every save in the remote repository.


I do not know if this is possible in Webcon, but until we ask, we will not know. :) Currently, Webcon is working on a new version of Designer Studio, so perhaps they could consider building in some kind of Git repository support.(not only dark mode ;) )

Cheers

MVP
In reply to: Franek

We have some kind of code due to the import/export mechanism → inside the packages there are XML files that could probably be saved, visualized, and versioned with every save in the remote repository.


I do not know if this is possible in Webcon, but until we ask, we will not know. :) Currently, Webcon is working on a new version of Designer Studio, so perhaps they could consider building in some kind of Git repository support.(not only dark mode ;) )

Cheers

Hi Franek,

I also looked at the .bpe packages and wanted to save the result to Git so that we could compare it if necessary. Yes, it would be a pain but it would have been feasible, if necessary. Then we installed a new version and the order of the XML elements changed a lot, this made us drop the idea.

I still have the file:
$sourceFile = "C:\Users\dkrueger9319\Desktop\Temp\BPE\Incident Management_9_2021_03_29 11_59_34_dev_package.bpe"
$targetFile = "C:\Users\dkrueger9319\Desktop\Temp\BPE\Incident Management_9_2021_04_06 13_47_03_dev_app_only.bpe"
. C:\Workspace\PoC\LS-DLC_Research_Lab\PowerShell\Compare_BPE_Files.internal.ps1
Create-ComparableBPEFiles -sourceFile $sourceFile -targetFile $targetFile

Damn, it's already been four years. :)