gilles.marceau wrote:
in my company, 2 teams works on 2 applications using the same database.
if you are using the "same database" there could be two types of possible breaks:
A. The database has breaking changes (e.g. column is renamed, remove column, etc). This would break the code, even if you don't sync and regenerate code.
B. The database has not breaking changes, however they (master team) made changes to the model. If you use the same model and generate, then you might notice breaking changes in your own code.
So, it would depend on what are you testing. If it's (a) and you don't share a common DAL project then I would recommend to pull they DB changes. The DB changes should be versioned (the scripts that alter tables and other things). Then in you local machine you should run your script at DB, then LLBLGen project sync and generate code, then run your tests. All of that could be automated.
gilles.marceau wrote:
=> Is there a way to refresh entities using another schema that the one defined in the llblgenproj file ? It would permit me to refresh entities from the database that has been modified by the 1st team and if rebuild failed, I will be able to know something is broken. Of course, I would be able to create a dump and restore this dump on my database but...
My advise is that you have a DEV database to test those changes. The dump, restore, apply scripts, etc., all that could be automated.
gilles.marceau wrote:
Note : I thought about creating an application which would make changes to the llblgenproj (change the database connection, the database user and password) before running "CliSyncWithDatabase.exe". Is there another way ?
Remember that in order to run CliSyncWithDatabase.exe you need to have the LLBLGen license in the folder with the .exe resides. AFAIK you CAN'T run LLBLGen command line tools that uses the license in Servers (e.g. Gitlab). So, please double check that. I would recommend to run the sync locally, then you can run your build/test pipelines in gitlab.
Said that, you can download the CliSyncWithDatabase source code. It shouln't be that hard to change the host of the database server. But as I said, I think you should use another way more practical, that involves forks in your repo, pull requests, DB script update history, etc.