| How BSI handles deployment [message #1839078] |
Fri, 12 March 2021 09:15  |
Eclipse User |
|
|
|
Hello,
Question to BSI employees..
What tools you use daily, how to you handle deploying on multiple servers, database altering on new deployment?
|
|
|
| Re: How BSI handles deployment [message #1839194 is a reply to message #1839078] |
Wed, 17 March 2021 06:33  |
| Eclipse User |
|
|
|
Hi Luka,
I'm one of those BSI employess you addressed and happy to answer your question .
As the scope of your question was rather broad, I'll give you a high level overview so feel free to ask for more details in specific areas if needed.
I understand, that your question mainly targets deployment into different environments and database migration.
Deployment
At the moment there are mainly two szenarios:
- building .war files and deploy to running Tomcat instances
- building Docker images; we use the Google JIB plugin for that which amongst other things comes as a maven plugin that we integrated into the build of our .war modules
Either way, the config.properties files of our .war modules only contain the static, known-at-compile-time information (e.g. application name, version or maybe some other property that is highly unlikely to change between the environments).
All the environment dependent property values are provided by the environment. This can either be OS environment variables, Java system properties or you can put these properties into a separate file and specify the path using the Java system property "scout.env".
This works well when deploying to Tomcat but especially providing environment dependent properties by environment variables in a Container environment (read Docker or Kubernetes) is really simple, straight forward and integrates very nicely with the tooling.
Have a read on chapter 2.4 in the "Eclipse Scout Technical Guide" for more information on this topic.
Migration
For database migration we rolled our own custom solution, that integrates well with our own JPA implementation but that also takes into consideration the fact, that we have to support multiple releases of our applications where on each branch, modifications of the database may occur (so the database migration is not just a straight line but several parallel lines).
For more simple use cases (just manage the progression of the database schema and also data migration for new releases) I would suggest to use some off the shelve library tool that does this for you. Ideally, the state of each database should be stored in the database itself, so that you don't have to worry about which migrations to run depending on the state of the database.
I don't know any tool in particular, but a quick google search brought up Flyway which might be a good fit for your use case.
You can either make the migrator its own tool, that is built on your CI system in parallel to the .war files or Docker images and then executed after stopping the application and before the deployment of the new release. That is at least how we do it at the moment.
On the other hand, I would now rather recommend to make the database migration part of the server application startup procedure so that new releases automatically perform a migration of the database. This is the preferred way in orchestrated container environments (Kubernetes) so that deploying a new version becomes as easy as modifying the image tag of some deployment and the rest ist handled automatically. Flyway, for example, may be directly called from java code. Maybe add some programmatical switch to disable migration in development environments so that you can migrate your dev database when feasable.
Anyway, I hope I could anser some of your questions, if you need more detailed information on any of the topics, please don't hesitate to ask!
Cheers,
Michael
[Updated on: Wed, 17 March 2021 07:02] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.03487 seconds
Home