thanks for the tips. We will start alternating versions with each deployment.
I have another question about managing <target></target> for queues that I will post under a distinct topic. thanks, Carter On Fri, Jan 13, 2012 at 3:16 PM, Ikai Lan (Google) <ika...@google.com>wrote: > Re: Carter > > Going a bit off topic, but in general I have always worked at places that > stage deployments. That is - you have some environment only accessible by > your team that reaches live data after your verification and QA more or > less have determined that in the worse case scenario, your change is not > destructive in a non-recoverable manner. Alternating versions is a very > good way to do this; it also offers you a very easy rollback path. Being > able to rollback quickly is absolutely key to working fast when things go > sour. If it were me, I'd always alternate versions on deploy and manually > switch versions when I have confidence the new version is good, but you've > got to find that practice that works best for you. There are bugs that only > rear their heads in production. > > The App Engine team more or less does major version releases by deploying > to test clusters, internal clusters, and then, via canarying, to the > production cluster. The way staging is usually done for new APIs is that > new APIs are usually available in production before we announce the release > (they may only be accessible to our whitelisted apps) so we can test that, > in production (because production is always a jungle), the new APIs work > well. We never do a rollout without first having a rollback plan, which is > what you get by alternating versions when you deploy your applications. > > -- > Ikai Lan > Developer Programs Engineer, Google App Engine > plus.ikailan.com | twitter.com/ikai > > > > On Fri, Jan 13, 2012 at 12:40 PM, Carter Maslan <car...@maslan.com> wrote: > >> Ikai - >> >> Our site was unusable for 30 minutes while we quickly downloaded the >> 1.6.1.1 fix and redeployed with the new SDK. >> >> We could have deployed in two phases with a different version so that we >> could have discovered the bug prior to being live. >> >> Is it best practice to alternate between versions with *each and every* >> deployment in order to catch deployment-specific bugs? >> Or do you think your deployment-related testing is sufficiently good that >> we can rely on the integrity of deployment? >> >> thanks, >> Carter >> >> >> >> On Wed, Jan 11, 2012 at 5:22 PM, Ikai Lan (Google) <ika...@google.com>wrote: >> >>> We have an SDK update that resolves this issue on upload (I've also >>> posted in a separate thread about this): >>> >>> >>> http://code.google.com/p/googleappengine/downloads/detail?name=appengine-java-sdk-1.6.1.1.zip >>> >>> -- >>> Ikai Lan >>> Developer Programs Engineer, Google App Engine >>> plus.ikailan.com | twitter.com/ikai >>> >>> >>> >>> On Tue, Jan 10, 2012 at 3:38 PM, Shawn Brown <big.coffee.lo...@gmail.com >>> > wrote: >>> >>>> > We think we know what's happening. This is something that is >>>> happening at >>>> > app upload time. Can you try setting a new version name for your app, >>>> then >>>> > passing the --no_batch option when using appcfg.sh? >>>> > >>>> > appcfg.sh --no_batch update [YOUR_WAR_DIRECTORY] >>>> >>>> >>>> Seems to solve it. I can't reproduce the error as I did by just >>>> modifying the spaces in comments in the css file anymore. >>>> >>>> Shawn >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Google App Engine for Java" group. >>>> To post to this group, send email to >>>> google-appengine-java@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> google-appengine-java+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-appengine-java?hl=en. >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Google App Engine for Java" group. >>> To post to this group, send email to >>> google-appengine-java@googlegroups.com. >>> To unsubscribe from this group, send email to >>> google-appengine-java+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine-java?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine for Java" group. >> To post to this group, send email to >> google-appengine-java@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine-java+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine-java?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > google-appengine-java@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine-java+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
