Multi-module stack projects

[christopherchapman]

If we are working on a multi-module stack project, what is a good rule-of-thumb for needing a deploy and a qa module? Here is an example. We have the normal setup:

Code: Select all

timelines/
    db
    deploy
    qa
    web (produces a war artifact)

We are also integrating with some of the FamilySearch services, so I have added the following modules:

Code: Select all

timelines/
  familysearch/
    api
    client

Do we need a qa and deploy module in the familysearch module? Or are those modules needed only when we are producing? Other modules are dependent on the familysearch/api module (including familysearch/client), so these artifacts will automatically be deployed to front-end integration testing.

Another question:
We have decided on a SOFEA application, and are encapsulating all the rich domain logic behind web services. We have created modules like this:

Code: Select all

timelines/
   ws/
     api
     deploy
     qa
     web (produces a war artifact for the web services)

Our thinking has been that this module group is a front-end system, so it needs the integration testing provided by qa, and could be deployed seperately, so we need the deploy module.

Are we on the right track?

[YoungstromMJ]

If we are working on a multi-module stack project, what is a good rule-of-thumb for needing a deploy and a qa module?

The deploy module creates a .zip that can be handed to middleware to deploy. That zip should include everything middleware needs in order to deploy (tomcat config files, .war file(s), etc). So, for every web project (.war) that you want deployed you need to provide a deploy project that contains the configuration for that web project. You can in theory include multiple web projects (.war) in a single deploy project (.zip) but that is only going to make sense if you know you're always going to want to deploy both .war files at the same time. It looks like here you have a web ui project and a web service project. The web service project you're probably planning to have multiple versions deployed at the same time for backwards compatibility so they will have different deployment profiles so they should probably have their own independent deploy projects.

It looks like the family search modules are producing .jar files that will be included in your ws and ui web projects? So they won't need a deploy project since they don't produce .wars.

The purpose of the qa project is to provide a place to perform black box tests against your deployed application. A qa project takes as a dependency a deploy project. When the qa project is built it will do a local deploy of the web project. Then any tests you write in the qa project will be run against your web application while it is running in a container.

So, if you want to be able to run black box tests against your web project you should have a qa project aligned with the deploy project you want to run tests against. Otherwise if you don't want black box tests run as part of your build then you can delete the qa project.

You can also set up your qa project to start up multiple deployables (assuming they're configured to run on different ports). This way if your ui project requires your ws project to be running in order to work then you can configure your qa project to deploy both your ws and ui projects before running its functional tests. You can see an example of this in the petstore: https://dev.lds.org/svn/stack/modules/pet-store/trunk/ Here our ui project depends upon our ws project. So the qa module for the ui project deploys both the ws and ui projects before running its tests. If you wanted you could also run web service tests at the same time in the same qa project as the ui functional tests. Though we chose to separate our web service qa project from the ui qa project in the pet store.

Another question:
We have decided on a SOFEA application, and are encapsulating all the rich domain logic behind web services. Our thinking has been that this module group is a front-end system, so it needs the integration testing provided by qa, and could be deployed seperately, so we need the deploy module.

Are we on the right track?

Yes I believe so. Does that help?

Mike

[christopherchapman]

Yes, Mike. That is very helpful.