These days, I don’t much like being ahead of, behind, askance of, or otherwise deviated from the curve. It used to fit well with my “blogging as a nervous tic” phase of early 2008 when I would apparently post about every single compiler error I encountered and how it fit in with the grand scheme of things. But now, I prefer my technology much more Google-able. Does wonders for my productivity. In light of that, this post will fall into the category of “interesting to people searching for a solution to a specific problem.”
And so it was that I went and tried to set up a CI process for our brand spankin’ new AppEngine app. (Note to you fetishists: I didn’t mean that “spankin’” part literally. I don’t pretend to understand the euphemisms I use; I just use ‘em.)
It’s essentially the same process we’re using for our main BookedIN application, which also runs on AppEngine:
Compile and test configurationIn this configuration, we just compile the app and run the unit tests.
Run stable UI testsThis configuration performs the following steps:
GWT compile the application. I.e. do all the magic that converts Java into JavaScript
Launch GWT hosted mode
Launch the UI tests
The first two steps are performed with Ant. The last is in Rake because the UI tests are done in Capybara. We launch hosted mode first because it’s orders of magnitude faster to run UI tests against a local hosted mode version than it is against a deployed version, especially because we clear out the datastore before each scenario.
Let me add some foreshadowing here. In order to launch hosted mode, we use the following Ant target:
1:
2:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
Note that this is running dev mode using the AppEngine agent. So it’s mimicking AppEngine behind the scenes…somehow.
The key to this target is where it says: spawn=”true”. This allows TeamCity to launch DevMode, then continue about its business. I.e. it doesn’t wait until DevMode is finished.
Run flaky UI testsWe have this one in here just because I got tired of seeing three or four failing tests every single time and 95% of the time, it was because of a PayPal sandbox issue. Having these “sometimes they work, sometimes they don’t” tests in a separate project means I can take the ones that fail in the previous configuration that much more seriously. All this configuration does is run UI tests that are tagged as @flaky.
Kill DevModeWe have this as a separate configuration because we want it to run always. If it’s set up as a separate step in one of the previous configurations, TeamCity won’t run it if any of the UI tests fail. As a separate configuration, it can be set to run after any build of “Run flaky UI tests” regardless of whether that build succeeded or failed.
The new app…
…is in AppEngine also but not in GWT (for reasons outlined elsewhere). Which I thought meant this would be easier. Alack, this is not true.
There is a corresponding “dev mode” in AppEngine. But it can’t be launched and then forgotten like it can in GWT. Here’s the target we originally had for it:
1:
2:
4: fork="true" failonerror="true">
5:
6:
7:
8:
9:
10:
Same idea as the previous one but with a different class name. And unfortunately, you can’t add spawn=”true” to this one. Something in DevAppServerMain doesn’t like spawn=”true” and complains. So if you run this target, it sits there and waits until you forcibly stop the server, either with Ctrl-C or something like the following (in another command window):
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
And so it was that I went and tried to set up a CI process for our brand spankin’ new AppEngine app. (Note to you fetishists: I didn’t mean that “spankin’” part literally. I don’t pretend to understand the euphemisms I use; I just use ‘em.)
It’s essentially the same process we’re using for our main BookedIN application, which also runs on AppEngine:
Compile and test configurationIn this configuration, we just compile the app and run the unit tests.
Run stable UI testsThis configuration performs the following steps:
GWT compile the application. I.e. do all the magic that converts Java into JavaScript
Launch GWT hosted mode
Launch the UI tests
The first two steps are performed with Ant. The last is in Rake because the UI tests are done in Capybara. We launch hosted mode first because it’s orders of magnitude faster to run UI tests against a local hosted mode version than it is against a deployed version, especially because we clear out the datastore before each scenario.
Let me add some foreshadowing here. In order to launch hosted mode, we use the following Ant target:
1:
2:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
Note that this is running dev mode using the AppEngine agent. So it’s mimicking AppEngine behind the scenes…somehow.
The key to this target is where it says: spawn=”true”. This allows TeamCity to launch DevMode, then continue about its business. I.e. it doesn’t wait until DevMode is finished.
Run flaky UI testsWe have this one in here just because I got tired of seeing three or four failing tests every single time and 95% of the time, it was because of a PayPal sandbox issue. Having these “sometimes they work, sometimes they don’t” tests in a separate project means I can take the ones that fail in the previous configuration that much more seriously. All this configuration does is run UI tests that are tagged as @flaky.
Kill DevModeWe have this as a separate configuration because we want it to run always. If it’s set up as a separate step in one of the previous configurations, TeamCity won’t run it if any of the UI tests fail. As a separate configuration, it can be set to run after any build of “Run flaky UI tests” regardless of whether that build succeeded or failed.
The new app…
…is in AppEngine also but not in GWT (for reasons outlined elsewhere). Which I thought meant this would be easier. Alack, this is not true.
There is a corresponding “dev mode” in AppEngine. But it can’t be launched and then forgotten like it can in GWT. Here’s the target we originally had for it:
1:
2:
4: fork="true" failonerror="true">
5:
6:
7:
8:
9:
10:
Same idea as the previous one but with a different class name. And unfortunately, you can’t add spawn=”true” to this one. Something in DevAppServerMain doesn’t like spawn=”true” and complains. So if you run this target, it sits there and waits until you forcibly stop the server, either with Ctrl-C or something like the following (in another command window):
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
