Deployment from 2022.12 and the future

Questions
1

Hey guys,

quick question or just a talking-point.

As i remember correctly from Servoy 2022.12 on, we cant import solutions (xxx.servoy) in /servoy-admin/ anymore.

I have a clientserver on which runs a tomcat 9 with my solution as .war. Everything is fine.

But quick question: if i change something in my code, even if its only one line. I need to export the whole .war again to update the solutions at my client.
On old projects, which are running a “standalone” servoy app-server that goes real quick, we export the .servoy → transfer that to the client (we??re talking about max 10mb) and import that solution in \servoy-admin. Thing is done.
The end-user just needs to restart the .jnlp file and he gets the one line change.

So all the new projects that are running on tomcat??s would be like this:

Export the whole solution as a .war → transfer the 150mb big file → stop the tomcat → copy the .war → start the tomcat.
All the end-user are getting kicked out of the solution in this procedure.

I just want to understand the explanation for this. Or maybe im just doing it wrong :D

Thanks in advance and have a nice week
Vik

edit: i reported this post from the developer and clicked on “Servoy NG Client” but it was posted in “Web-Client” maybe a mod can move it to the right section. Thanks

2

you don’t need to stop really tomcat, you could just deploy the new WAR again
But yes that does mean the users are kicked out for a moment.
(because the context, the application running in tomcat, is undeployed for a moment)

The thing is that the WAR is the build artifact, that’s what is run, everything belongs together with that.

So that is currently how it goes, we don’t really have quick inline patches support anymore like that.

3

thanks for the info johan!
Now i kinda get why it is how it is :)

I guess we need to introduce patch-times for our customers that would be the best practice.

4

If you switch to servoy cloud, you can have zero downtime for users.
We will start a new node (with tomcat) and route new logins to that. The 2 tomcats are connected for databroadcasts.
After a while most people are logged out of the old tomcat (or we log them out forced) and thats turned of.

Would this help?

5

Hey rvanderburg, yes we´re planning on using svyCloud for a future product.
In this particular example a cloud solution is not gonna work because we´re working alot with file.IO stuff. Alot of word-files and such.

But in the planned project we want a full SAAS solution. I already testes svyCloud last year and i was very impressed. Im gonna contact victor as soon as i have a fixed plan for the project.

It would be cool to have detailed information on how to “imitate” svyCloud for inhouse testing. From the git-pipeline to jenkins and all the tomcat settings and quirks.

I found a old pdf and guide, but its really old and probably outdated.
You guys are not planning on releasing a detailed guide on how to setup for example git/bitbucked pipelines, tomcat databroadcasts, etc?

Actually i would really appreciate it if i get to know how to generate a .war file out of my bitbucket branch…just because i cant find a servoy-specific way of doing it and i find it really interesting :D

6

Vik,

Sorry we are not going to document how we build servoy cloud. We use a lot of technologies we did not build ourselves :)
What is documented is how to generate a war file from the command line, which is the way the war is generated in our pipeline:

https://wiki.servoy.com/display/DOCS/Co … it+Testing

7

vik.lamp.vl:
Hey guys,
quick question or just a talking-point.
As i remember correctly from Servoy 2022.12 on, we cant import solutions (xxx.servoy) in /servoy-admin/ anymore.
But quick question: if i change something in my code, even if its only one line. I need to export the whole .war again to update the solutions at my client.

WHOA!!!
I had not noticed this change!
This is a huge change and NOT for the better.
Won’t this then mean we won’t be able to rollback releases???
I thought that one of the reasons for having the repository database was to allow multiple versions of a solution to be imported and if there was an issue with an upload/release, it was super easy to rollback to a previous version!
This will be a big change for how I deploy solutions for clients (that at some point I want to bring up to the newest version of Servoy).
The way Vin refers to was so easy, just export a WAR of everything ‘Servoy’ except for solution & then import ‘.servoy’ files each time a change/changes are made & then there is the safety of knowing you can just ‘flick a switch’ & roll back to a working release if something goes wrong.
I’ve allowed the right person (admin level) at my clients access to Servoy web admin so that if I am ‘offline’ after uploading a release, they can easily get back to work by logging out, activating earlier release and then going back in.
How on earth will they be able to cope now if something goes wrong???
I don’t want them accessing the Tomcat server and playing around with WAR files!

PLEASE somehow reconsider this, I think this will impact a LOT of long term Servoy developers…
(I know you don’t need to ask us mere mortals on what you want to do with Servoy moving forward, but this is a massive change [and not all of us can or want to use Servoy Cloud…] )

Thanks

Rafi

8

Hey Rafi,

yup we where doing the same. Rollback quick and easy if something is broken and was missed in QA.
I just looked up our client with 2022.12, there is no solution-version to rollback. So either i am blind or it wont be possible to do that anymore.
I posted a screenshot of /servoy-admin/solutions/

Servoy Cloud is great but for some projects not viable i agree.

I hope there will be development in the future of /solutions/

-Vik

_s2022_12_solution.png
_s2022_12_solution.png786×374 10.1 KB

9

no rollback means setting the build artifact back which is the WAR
So you just have WAR versions like 1.0, 1.1, 2.0, 2.2

The problem is that it is not just the solution that makes up something, it is way way more, dbi files, webcomponents, angular builds. plugins, extensions.

The repository is not used a lot in all the new deployments, most people i guess just use some inmemory repository. Almost in all deployments (exporting WAR with solution) the solution is read from disk as is, which is way faster then reading it in from a big repository database over many tables.

This will not be changed back, but we still allow exporting without a solution and you are in the old mode. But you really should be moving forward, the “solution.servoy” is not your build artifact, the WAR is the complete build.

10

vik.lamp.vl:
Hey Rafi,
yup we where doing the same. Rollback quick and easy if something is broken and was missed in QA.
I just looked up our client with 2022.12, there is no solution-version to rollback. So either i am blind or it wont be possible to do that anymore.
I posted a screenshot of /servoy-admin/solutions/
Servoy Cloud is great but for some projects not viable i agree.
I hope there will be development in the future of /solutions/
-Vik

Thanks Vik for checking,
I hope there is something that can be done, but not looking positive from what Johan says…

11

jcompagner:
no rollback means setting the build artifact back which is the WAR
So you just have WAR versions like 1.0, 1.1, 2.0, 2.2

That is a lot more space/time heavy & certainly not easy/possible for normal clients to be able to do…

The problem is that it is not just the solution that makes up something, it is way way more, dbi files, webcomponents, angular builds. plugins, extensions.

Obviously if I needed new components, plugins or extensions, I would do a new WAR export, but if, like Vik, it’s just some basic code changes/updates, then the ‘.servoy’ file was so easy…

The repository is not used a lot in all the new deployments, most people i guess just use some inmemory repository.

Really, maybe a quick poll of forum users on how they deploy might be helpful to see what they do and if you are correct…

Almost in all deployments (exporting WAR with solution) the solution is read from disk as is, which is way faster than reading it in from a big repository database over many tables.

So are you now telling us that importing multiple solutions can have a detrimental affect on performance? Surely Servoy is very fast at reading from large, multi table databases, as that is what all of our solutions do??
At what point (number of release imports) does it go ‘bad’?

This will not be changed back, but we still allow exporting without a solution and you are in the old mode. But you really should be moving forward, the “solution.servoy” is not your build artifact, the WAR is the complete build.

So where is is documented what ‘old mode’ is/means?
What don’t we get, as stated by this check box??

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

Nowhere on https://wiki.servoy.com/display/DOCS/2022.12+Whats+new can I see any mention of this ‘game changer’, where was it mentioned/explained/detailed/documented??

Thanks

Rafi

12

rafig:
PLEASE somehow reconsider this, I think this will impact a LOT of long term Servoy developers…
(I know you don’t need to ask us mere mortals on what you want to do with Servoy moving forward, but this is a massive change [and not all of us can or want to use Servoy Cloud…] )

Thanks

Rafi

+1

13

rafig:
PLEASE somehow reconsider this, I think this will impact a LOT of long term Servoy developers…
(I know you don’t need to ask us mere mortals on what you want to do with Servoy moving forward, but this is a massive change [and not all of us can or want to use Servoy Cloud…] )

Thanks

Rafi

+1

14

rvanderburg:
Vik,

Sorry we are not going to document how we build servoy cloud. We use a lot of technologies we did not build ourselves :)
What is documented is how to generate a war file from the command line, which is the way the war is generated in our pipeline:

https://wiki.servoy.com/display/DOCS/Co … it+Testing

Checked out the doc, will test it out. (Still dont know how to apply that command line exporter to the pipeline, what prerequisites do i need, etc. But i will get it to work somehow.)

But the link in the doc (Servoy Software Factory Example using Jenkins Security: Cross-site Scripting | Docs) in the paragraph “Test Suite Runner” is private. Even with a loged in account.

Dont get me wrong, i appreciate the work you guys are doing and i see the vision behind it. And the reaction time for issues is good.

But just like Rafi said, more documentation is needed for the changes you guys are doing. Dont get me wrong, the github wiki (for components) and docs got ALOT better in the last year but it still lacks some info, examples and explanation, in my opinion.
I remember at svyWorld you guys showed a new Wiki Site where you showed stuff like “generating own components”. Cant find the link rn, will edit when i have time.
But last time i check it was still at the same as it was when released. No new infos.

Alone the whole CSS part in Servoy is very finicky. Where updating all our solutions form smart-client to TI. Half the CSS we do (which works in a plain html/js/css constelation) does just not work without workarounds in a servoy-full-css-form. Maybe im just stupid and dont get css. But it still would help alot if we get more docs beside the samplesolution (which if you resize it for example just breaks the css ;) )

-Vik

15

+1

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

What features would be missing? Is it just updates from the Servoy Package Manager?

16

+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.

17

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:

jcompagner:
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.

18

Hi Marc,

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.

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

[] 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…]

mboegem:
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…

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

jcompagner:
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…

mboegem:
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… :wink:
Thanks

19

Hi Rafi,

rafig:
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.

20

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

Thanks Marc!