Thanks for your reply... I am a little bit late due to vacation.
Exactly
Shinytest looks reallygreat but as many cool packages it doesn't have a stable release yet on cran (devtools::install_github("rstudio/shinytest")??) so I cannot really use it, especially as the install_github is not working in our intranet due to our proxy.
Actually I'm doing that already, otherwise I could not restore the needed packages on my testing server/jenkins slave (NOT shiny server)
Thats actually a good idea - if I still make the Shiny Server a Jenkins Slave I could use stach/unstash to do the same. I will check which is more elegant and generic.
As for now neither would work though as the Jenkins Slave is a windows client and the Shiny Server a Linux client for historical reasons... but this setup not optimal in any case.
Thats true but to follow Infrastructure as Code principles I put the config now in GitHub anyway... and currently its very convenient to e.g. change Shiny Server Timout settings and such directly via Git(Hub) Commit
We had not so good experience with a product from the competition that kinda tried to lock the development including deployment/sheduling and such into its own ecosystem - thats why I am little bit more carful now. I work in a company with more than hundred thousand employes - if would be catastrophic if every department chooses its own ecosystem. There need to be some kind of generally accepted stardards of principles and environments that do not depend on programming languages. That will help too, when someone new (eg. some Software Engineer) has to be trained.
Thats why I really love Shiny Server Pro so far as its very lightweight and can be easily integrated in established environments.