I want to have a automatic deployment of my test system on every night to the dev#cloud system of cloudbees.
The problem is now that I use the dbm-update goal on grails and its trying to update the database from Jenkins. This is a problem because the com.cloudbees.jdbc.Driver is not available in this context. Only if the app is deployed to the test sytem.
Does somebody tried this already and can help me out with some tips how to solve or workaround this problem?
Thanks
You can set the updateOnStart flags in the plugin for your application in the test context,
grails.plugin.databasemigration.updateOnStart = true
grails.plugin.databasemigration.updateOnStartFileNames = ['changelog.groovy']
This will run the migrations when your test application starts, making you not need to do a separate dbm-update. Since this uses the same JDBC drivers as your running application, it should work.
Look at the RUN console (https://run.cloudbees.com) - there you will find your MySQL settings
You can just use a standard MySQL JDBC driver to connect to the MySQL database from anywhere (including from DEV#cloud and your test cases).
Related
My Grails app is based on
Gradle with Grails 2.4.4,
Tomcat plugin 7.0.55,
and MySQL plugin(mysql:mysql-connector-java:5.1.29).
Do I need to install Tomcat on the server?
Do I need to install MySQL on the server?
Both Tomcat and MySQL are not installed on dev environment(on my PC), but it seems working.
Container
While all the other answers pointed out, that you need already a container (which of course is true) there is also the option to use one of the "standalone" plugins (like e.g. https://grails.org/plugin/standalone). This will package your app as a fat jar, where the container and your app are part of a jar, that you simply run by java -jar myapp.jar (of course your would integrate that into your regular startup scripts on the server).
This is in general no bad option, since many WAR-deployed apps don't need any of the full blown container features anyway and you would be able to configure everything in place for your workload and don't have to compromise for all running wars (or your ops team). On the downside, if there is a security problem etc. with the container you would have to roll a new jar.
/With grails 3, which uses Spring Bootstrap, this even is a default option, since the preferred way of deploying. Spring Boot 1.2 supports Tomcat, Jetty, and Undertow by default./
Database
You can use a MySQL from "somewhere" else. But this is nitpicking, since you really need a MySQL somewhere (BTW: you really should start using MySQL also for your dev env, or you will be in for a few surprises once you put your stuff over to production).
Also be aware, that you can also keep using your H2 (see your datasource config) with files. This is an OK option (that saves you from installing a DB server) for small amounts of data you are storing and also there are other free database servers like PostgreSQL.
Obviously you have to install mysql and tomcat on the server.
During development you run grails from console, so you dont need tomcat as it will use embedded tomcat but still you need to have mysql installed, if you want to use mysql.
But on production, you create a war of your app using 'grails war command' and you deploy this war to a web container just like any other war, so you need tomcat and you will need mysql installed too.
In one word answer is 'Yes'.
Fact is when you are in development environment grails uses as an embedded tomcat server provided by the 'Apache Tomcat plugin' which version corresponds to grails version.
You've not installed mysql and you claimed 'it seems working'. That's funny! But it's not mysql who is working without being installed(!), rather it's also an integrated database provided by the 'H2 Database Plugin'.
So, when you'll deploy your grails app in Linux or another server certainly you need a tomcat server to handle user request to that app and a database where your data will be saved.
I am following this tutorial on Grails and Cloudbees And it says :
"to use CloudBees databases locally from your application, you first need to add the CloudBees SDK's appserver.jar file to your grails classpath"
Does anyone know what is this appserver.jar? Where can I find it?
Yes, as mentioned in the comment - you can get that jar file from the SDK you download.
However, it is perfectly find (and possibly better) to use the mysql driver directly as mentioned.
When running on cloudbees, you can bind your app to a database - so that at runtime the right database is injected - using the bees db:bind SDK command.
I am working with the webtest plugin as functional test component for grails.
It works fine, but is very slow - the whole application has poor response times (>1min per page) when under test. My feeling is that this is because the app, canoo webtest and the IDE (netbeans) are running in one JVM when I start my test through the IDE (test-app functional:)
So my goal is now to deploy the app to a stand-alone tomcat and run my tests against this tomcat instance.
I googled and found an old option -nostart for webtest which seem to be outdated.
So I googled some more and found the -baseUrl=http://... option in the current documentation. The docs say that with this option, the app will not be started and all tests will run against this baseUrl. But when I give it a try, grails still tries to start up jetty (at least, I get an error message saying that the port 8080 is already in use).
Any ideas? I am already thinking about using webtest stand-alone, but I like the groovy syntax of the plugin...
I'm using grails 1.3.4
You could try interactive mode as mentioned here: Can I run grails integration & functional tests against a running server?
If the -baseUrl option isn't working then I'd raise a JIRA issue.
cheers
Lee
I'm finding the feedback look pretty slow when running integration and functional tests in Grails. Is there a way I can run them against a running server instance while I'm writing the tests, to save on server startup time each time they're executed?
You can use grails interactive which does what you want without starting a server. It starts a JVM and keeps it running and you can use it to run unit and integration tests. Keep in mind that you'll eventually run out of memory and need to restart periodically. See http://docs.grails.org/latest/guide/gettingStarted.html#usingInteractiveMode
Also in 1.3.5 you can run functional tests against a running server. Use the baseUrl attribute described in section 9.3 at http://grails.org/doc/latest/
there's an option --baseUrl
e.g.
grails test-app --baseUrl=http://localhost:8080/myapp/
that runs tests against a running instance, one draw back is that the slate isn't wiped clean after a test, so if your test writes to the db, uploads a file, or some other permanent change to the application, then you may have to do some tearDown.
This is briefly documented at the end of the function testing section of the grails docs
http://grails.org/doc/latest/guide/testing.html#functionalTesting
It's useful for writing/debugging functional tests
I'm using Grails 1.3.5 and the EasyB plugin for stories in the context of functional tests.
Take a look at http://padcom13.blogspot.com/2010/10/grails-easyb-and-selenium.html for step-by-step instructions.
I'm using IBM RAD as the IDE and Websphere Application Server v6.0 to deploy applications.
I'm working on a EJB application and build it using ANT and then deploy it using the Admin Console of the server. For every change this deploying is time consuming. 'Run on server' on the EAR file does not work sometimes.
Is it possible to automate the installation of the ear file too?
When I build the ear file, I should be able to deploy it to the server too from command line or from ant script.
Can you please help me with your suggestions?
Try the Rapid Deployment (WRD) and see if that helps you.
Pretty much what you do is drop your EAR into a designated directory that WRD monitors and it takes care of the installation,uninstallation and updates.
The best alternative is to have the build script that does the installation using ws_ant tasks. For a start i would suggest you try this approach too and see if that is useful.
HTH
Manglu
First, my usual pattern using RAD is to have a WebSphere Test environment set up and "run with resources in workspace". This is quick, requires no extra build or deploy steps, no routine use of the admin console.
Sometimes one does need to make sure that everything on the server is tidied up - then I remove the projects from the server (in RAD) and also make sure they are stopped and deleted in the admin console.
Second, everything you do in the admin console can be scripted using the command line tool wsadmin. So yes you can deploy your ear files automatically. If you are intending to do that I recommend that you create a new Server profile, do not run it from inside RAD - just to avoid confusion.
I only use stand alone servers for specialised testing, it's clearly more work that the simple save and run made possible when running on a test server with resources in workspace.
If you find the native RAD approach unreliable I suggest you add some mroe questions ... it does work in general.
Agreed, keep the setup simple as possible and create the project from scratch in RAD to make sure it deploys ok.
Bit of a pain as you will then need to maintain a separate ant script but RAD does work well in general.
Karl
It's pretty easy to write a wsadmin script that will update/redeploy your application after you rebuild.
-Rick