Deployment from 2022.12 and the future

[ptalbot]

+1

I'm also curious about what the newest features would be missing... I saw this but haven't found out what this means anywhere.

[mboegem]

I don't really see what this discussion is about...

For quite some time you have 2 options when working with war deployment:
1) export war-file including your active solution (and optional solutions)
2) export war-file without the solution.

The 2nd method allows you to import solutions as you were used to, through the admin page.
Looking at NG it's good to realise that all of your webpackages are exported with the war and not with export of the solution
So when you are using a new web component you will need to update the war file, this is kind of similar to adding a new plugin/bean to the application server in the past. Which sometimes required restart of the application server (so downtime)

When I see Johan's response, nothing seems to change here:

but we still allow exporting without a solution and you are in the old mode

For all people finding this 2-step approach confusing, there's also something in tomcat called 'parallel deployment'.
Basically this is using the version number in your filename to spin up a 2nd container of your solution in the same tomcat instance.
Alle new sessions will be directed to the newest versions and old sessions will continue to use the old version (until shutdown, tomcat will cleanup the old container when all sessions are gone)
Having 2 war-containers means 2 application servers, meaning you will have to setup RabbitMQ in order to handle data-broadcast between those.
This approach allows deployment of the full war-file without downtime, but requires some setup and thinking about situations like shutting down batch-processors on the old version.

[rafig]

Hi Marc,

I don't really see what this discussion is about...
For quite some time you have 2 options when working with war deployment:
1) export war-file including your active solution (and optional solutions)
2) export war-file without the solution.
The 2nd method allows you to import solutions as you were used to, through the admin page.

The discussion is about the fact that there now does seem to be some difference as there is a comment

Code: Select all

[] Include active solution and modules a war export without solution does not support newest features)

and we are trying to find out what features we will not have [no docs on this...]

Looking at NG it's good to realise that all of your webpackages are exported with the war and not with export of the solution
So when you are using a new web component you will need to update the war file, this is kind of similar to adding a new plugin/bean to the application server in the past. Which sometimes required restart of the application server (so downtime)

I get that and do that, of course...

When I see Johan's response, nothing seems to change here:

but we still allow exporting without a solution and you are in the old mode

See my above comment, it seems it's a bit more than just 'old mode', there seems to be a difference in features doing it the old way...

For all people finding this 2-step approach confusing, there's also something in tomcat called 'parallel deployment'.
Basically this is using the version number in your filename to spin up a 2nd container of your solution in the same tomcat instance.
Alle new sessions will be directed to the newest versions and old sessions will continue to use the old version (until shutdown, tomcat will cleanup the old container when all sessions are gone)
Having 2 war-containers means 2 application servers, meaning you will have to setup RabbitMQ in order to handle data-broadcast between those.
This approach allows deployment of the full war-file without downtime, but requires some setup and thinking about situations like shutting down batch-processors on the old version.

The first bit sounds great (what is naming convention though for WAR files & version numbers??), but I have no idea how to set up RabbitMQ...
Thanks

[mboegem]

Hi Rafi,

The first bit sounds great (what is naming convention though for WAR files & version numbers??), but I have no idea how to set up RabbitMQ...

Versioning is [containername##v2.0], where part after hashtags can be anything.

[rafig]

Versioning is [containername##v2.0], where part after hashtags can be anything.

Thanks Marc!

[jcompagner]

[quote="rafig"
The discussion is about the fact that there now does seem to be some difference as there is a comment

Code: Select all

[] Include active solution and modules a war export without solution does not support newest features)

and we are trying to find out what features we will not have [no docs on this...]
[/quote]

Stuff about those new features are described in the release notes of 2022.09

https://wiki.servoy.com/display/DOCS/2022.09+Whats+new

this is about the part of "columns sort on null and sorting case insensitive

that is stored in DBI files. even now at the server level (instead of just the column level)
those DBI files that you have in the developer, are now included in the WAR "as is" so no more repository "column_info" table

So if for example you use this in the server editor:

server_editor.png

that information doesn't get into the WAR when you are just using .servoy files (because the .servoy file doesn't have that)

[mboegem]

Hi Johan,

can you please confirm recap below (so I'm not assuming things that are not written)

1) Clearly, this change was already part of 2022.9
2) Exporting a .war file INCLUDING the solution will generate a .war file which holds the table/column information in .dbi files and no longer in a repository.
3) Exporting a .war file WITHOUT the solution will allow you to import solutions and will still store the table/column information in the repository (also read: an import of the new solution can actually add columns to the DB)
4) Only when deploying full .war file (including solutions) you will have the ability to configure the behaviour of Servoy when it comes to sorting records.(nulls first/last and/or ignore-case)

Thank you!

[jcompagner]

yes

[rafig]

Stuff about those new features are described in the release notes of 2022.09
https://wiki.servoy.com/display/DOCS/2022.09+Whats+new
this is about the part of "columns sort on null and sorting case insensitive
that information doesn't get into the WAR when you are just using .servoy files (because the .servoy file doesn't have that)

Thank Johan for letting us know (& your reply to Marc).
I think I might be able to cope with not having that new feature, so will carry on 'the old way'

[sbutler]

For those less comfortable with WAR deployment, Servoy Cloud is probably the best way to go. I haven't personally used it, but webinars and stuff I've seen on it look pretty great.

If you are looking for alternatives and Servoy Cloud doesn't fit for your situation, we do have automated deployments working with many clients on many different cloud services (AWS, Azure, Google, In house, etc). Its something we do for our consulting customers, but we haven't "packaged it up" into something that could be offered to other consultants/developers. Its not as fancy and Servoy Cloud, but does work well. Essentially its GitHub actions that build (and optionally deploy) your WAR file based on commit tags or messages, so you control when it happens. If there is enough interest, we'd consider formalizing that into something that could be easily used by others and able to be purchased (or included for those that already purchase our All Products Pack bundle)

[rafig]

If there is enough interest, we'd consider formalizing that into something that could be easily used by others and able to be purchased (or included for those that already purchase our All Products Pack bundle)

If the price is right, sounds good! +1

[sbutler]

If the price is right

Sounds like Rafi!

[rafig]

If the price is right

Sounds like Rafi!

LOL
That's me

[sean]

War deployment is covered here:
https://www.youtube.com/watch?v=uPVM9GJL-gY
(A bit old, but still relevant)

Also just to clarify something I read above:
One does NOT need the command-line exporter, unless they want to automate their war file generation. I'm just worried that someone reading this thread would infer that generating a war file is necessarily a complex programming challenge. It is not.

[vik.lamp.vl]

If there is enough interest, we'd consider formalizing that into something that could be easily used by others and able to be purchased (or included for those that already purchase our All Products Pack bundle)

+1