On 19 May 2011 00:37, googelybear <[email protected]> wrote: > This build I am trying to optimize is compiled on our build server by > the continuous integration tool (hudson in our case triggered after > every commit). It is mainly used to run unit tests and for general > testing by the developers to get "instant" feedback (well, it used to > do that when we started). It is not a production build. But I don't > like to take too many things out, e.g. take out browsers then you can > no longer test it on different browsers and your feedback cycle - the > time until you notice something doesn't work after you implemented it > - gets longer). For the production build then it is absolutely OK to > take longer.
In general, I don't think it is a good idea to have one build for (many) different purposes. For unit tests you don't need all browsers so pick one and stick with it. In fact, for unit tests you don't need any browser. :-) Your unit test build can and should be very fast. This should be the most stripped down version you can think of. Mind you, it would be even better if you broke up your app into separate modules so that all the unit testing is done in the small, fast module builds. The second build would be for integration testing. For your automated integration testing you don't need more than one browser either. (Unless, of course, you have a very advanced setup testing multiple browsers.) Run this build once or twice a day at a specific time (say lunch time and dinner time). (The specific time is so that people know about it and can try to make sure their change is (or is not) included.) If the automated integration test build is successful then kick off the full build for all browsers. This need only happen once a day or even once a week. This build is then used for manual testing. It should be auto deployed to some QA/test environment. Most (test/QA) people don't like working with a moving target (for obvious reasons), hence the "build once a week" suggestion. Then, if QA says this build is good, promote it to production; no need for another build. I.e. assuming you follow the best practice of not including your environment configuration in the WAR. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
