I am trying to understand your process.
* Are you indicating that users develop on their local machine. Changes then need to be migrated into the production environment
* Only the IT administrator can update production
* The server then reloads and publishes the application from the server.
Therefore is the problem lies around how the developers ensure that the correct artefacts are moved to production? I have seen the following as solutions
* Manual change logs identify which files need to be moved.
* Rather than manually tracking changes you could leverage SyncToy to compare files. SyncToy - Wikipedia
* Finally you could implement a more robust solution using GitHub.
1. Master Container is stored in GitHub.
2. Developer checks out's repository. makes changes and then pushes the changes
3. IT Admin pulls updated repository from github
Using Git you would want to use gitignore to only sync code files. I.e. ignore QVDs and data files.
I hope this is useful.
Hi Georg, As Damian stated versioning is a good way of controlling local development. You can also create "self-service" containers, one per user (usually under a sub folder). See to it that the users have access to the the personal central container, now they can copy the container to the laptop start develop and copy the container back up again replacing the old.
I think this "self service Container" is a good solution. I will create it along with templates and the most important company-specific settings. Users will download it, modify and then the IT will reimplement it in QDF. GitHub is an interesting suggestion, but unfortunately not allowed for us. Thank you both!