Hello,

We are starting to design our continuous integration system.

The path we choose to go is automated test cycle: Get fresh environment (17
web services, distributed on ~6 EC2 instances), plus GAE as the super
scalable front end. Start running functionality tests on the system. Should
the tests pass do auto deploy to staging.

Now comes the tricky part: We can get EC2 instances up/down easily via API,
not quite so for GAE. It would be cool to have the same API for GAE yet we
don't... (yet?).

The solutions we currently consider, are:

   1. Have *N* GAE "applications". One of which will be the production one,
   use others as a pool for testing resources. This is not any way perfect
   because we need to clear the datastore after each test cycles finishes, plus
   you must always deploy the same "version number" to replace the existing
   version before you launch the test.
   2. Reverse engineer the web interface of appengine.google.com. Then we
   would create a randomly named instance (UUID or whatever), run the tests on
   this instance and then delete it.
   3. Deploy to a different version on the production application.
   4. Have 2 applications "Production" & "Staging". For staging define
*"N"*versions which will be used for testing. Implement DataStore and
Memcache
   partitioning in code so that versions don't override each other data
   records. Then each test environment deploys to a specific "version" on the
   staging environment.

The first solution is not cool because it has lots of possible failure
options, plus it limits us to the number of environments we can concurrently
run (probably not an issue, there shouldn't be more then 3-5 running at any
given time).

The second solution requires a process of RE the HTTPS calls, plus creating
many GAE applications and then deleting them is something the seems to be
not good for GAE. From what it seems applications are logically deleted --
Hench we would be creating lots of noise for short lived GAE applications...
We would want to create a harmful process.

The third option is still not bright, some of the versions might bring
DataStore scheme changes. This is OK for rolling update as long as we don't
need to roll back... but since the deployed version is part of a test cycle
(haven't been deployed on staging yet) the currently in production version
will use the older scheme so things will break.

The forth option requires changes in code, and might become fragile to code
changes. Plus it also requires cleaning the datastore & memcache at the end
of a test cycle process.


So, did any one here did something like this? I would appreciate input /
suggestions.

Thank you,
Maxim.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" 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-appengine?hl=en.

Reply via email to