O
onnodehaan
Guest
Hi We have a fully automated build environemtn. Every single file that is checked in starts a new "trunk" build. When we commit a DF-file, we start an "update database"-job after office hours. That triggers a rebuild of our master "test" (trunk)-database.Takes about 15 minutes. After the build is complete, we restart the Docker container for "trunk" and after a minute or so, all dev/test environments are up and running again and using the new database. Weekly updates for our Minor-releases, are also generated and published automatically, but never contain DF-files; since database-conversions are rather slow for large(r) customers. Would be great if we could use multi-treading for database-conversion programs btw. Spawing more than one session is troublesom, because of locking issues. As mentioned before, only our Major releases (yearly) contain DF-files. So, because we have automated everything, using AWS / Docker etc, the need for online-schema updates for Development is non-existing in fact. Updating customers is always done via an installer scripts, which is as simple as this example: - start script on Unix or start .CMD on Windows - Type: INSTALL, press ENTER - Type 2019.2.4 press ENTER Version 2019.2.4 is downloaded, unpacked, installed, database is updated, converted, all automatically. If the users uses clients, they need to be updated using the same procedure, but mostly customers use a few terminal servers or some way to use remote clients (Citrix image, etc)
Continue reading...
Continue reading...