Git Deploy
Roch Delsalle
Brandon Wirtz
Why would that save a lot of bandwidth?
Personally I hate GIT. It has to be one of the single worst ideas of all time.
Git is the tool for programmers who think they work in companies/project bigger than they do.
Git only comes in to usefulness if your code is measured in Gigabytes. Since your limit on GAE is something like 150 megs, you aren’t ever going to be a size that you need Git to deal with the huge code base and incrementals.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Barry Hunter
Request tracking)
http://code.google.com/p/googleappengine/issues/list?q=GIT
Although #480 is close.
Jeff Schnitzer
Brandon Wirtz
Git is one of the worse Revision Tracking solutions there is though. I have worked projects with over 1k dev’s dealing with trunks and branches, revs and regressions. And yes we used GIT some of the time and SubVersion some of the time, and other tools some of the time, but that isn’t the point.
GIT has no place in the Deployment chain. You would never integrate the push to your live environment with GIT, and GAE is just the “live environment” .
GIT’s advantage is supposed to be that it doesn’t have to store 100 copies of the same file for every version and sub version of your code. But the truth is it doesn’t do a good job of this…
But I digress from the point which isn’t “GIT SUCKS” it is that GIT is not a deployment tool. Using GIT to push files to GAE would only end in much heart ache when it does one of its infamous “I didn’t think white space matters” or “what do you mean I can’t much with the line feeds” or “you mean GAE Python27 and 25 and 27beta all detect as PYTHON? Let me GIT ‘the’ Python version for you.”
As a deployment tool GIT would only save up to 150MB of bandwidth if you had the maximum size app, and only changed 1 line of code. As someone who does my debugging on GAE not on a local instance, I get that it would save me 45 seconds each iteration. But the one time GIT screwed up. And it would. I would lose any efficiencies.
solsTiCe d'Hiver
Even if you make good points, it's sound like troll most of the time.
Brandon Wirtz
It’s not meant as a Troll. People often make feature requests to make things work more like they are used to working. If you have lived in GIT for the last X years, you know GIT and you think it is awesome because you have learned it’s quirks. I had a classic MG Roadster same deal, I loved it even though it was quirky and I could work around its issues, but you couldn’t loan the car to anyone because they wouldn’t make it 5 miles without something going wrong.
GIT solves problems that shouldn’t be part of the deployment process. And GAE shouldn’t be part of the Dev Process, that will make it more proprietary and create more work flow issues overall not less.
All the parts are there, if you want to build a script to have the APPCFG tool use the a given GIT build it is about 6 lines of code to do this integration. You won’t “save bandwidth” but you can have the checkout process be part of your deployment workflow.
And Eclipse has GIT integration so if you are working on Java you can do the same thing in 20 lines of code.
But having there be a button in your dash board that fires git, to place the code in to production will end in heart break.
-Brandon
From: google-a...@googlegroups.com [mailto:google-a...@googlegroups.com] On Behalf Of solsTiCe d'Hiver
Sent: Thursday, November 17, 2011 1:29 PM
To: google-a...@googlegroups.com
Subject: Re: [google-appengine] Git Deploy
You're on a good path to open a site called 'git haters'.
Even if you make good points, it's sound like troll most of the time.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/DCNmtxz1DkEJ.
Aaron C. de Bruyn
> GIT solves problems that shouldn’t be part of the deployment process. And GAE shouldn’t
> be part of the Dev Process
Really? If your production app is on GAE, you're telling me that you
should have a staging or test area on GAE?
And if "GIT solves problems that shouldn't be part of the deployment
process" is correct, git is still solving a problem--even if you don't
think it's the correct way. Make a better deployment process for the
people who have solved their deployment process using GIT and get 'em
to switch.
I personally use a combination of fabric and whatever VCS my project
is in to deploy applications to staging and production. But you
appear to be telling me that if I tag a release in git, then use
fabric to update the git repos on my servers to that tagged
version--that my deployment process is wrong because a VCS named 'git'
is involved?
Would you tell me the same thing if my VCS was subversion or cvs
or...etc? How do you get your code out of a VCS into production?
-A
Jeff Schnitzer
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
Brandon Wirtz
Actually, The Release manager pushes to our Staging App.
Testing is done with the staging data.
Appcfg sucks the code down from Staging. A script renames the App in the
APP.Yaml
AppCFG pushes the Code to a non-default version on the live APP. More
testing is done
Version is made live. More Testing is done.
In so doing no code is ever pushed to the "Live" app that hasn't been tested
first.
In our case we actually have 2 live apps, one supports a smaller volume of
traffic that is not from our clients. It runs "latest"
And the primary app runs "release". This allows us to load test before the
final deployment.
So it is actually Staging -> Test Pass -> Live non-default -> Test Pass ->
Live Default -> real word testing -> Primary Live non-default -> Test Pass
-> Primary Default
-----Original Message-----
From: google-a...@googlegroups.com
[mailto:google-a...@googlegroups.com] On Behalf Of Aaron C. de Bruyn
Sent: Thursday, November 17, 2011 2:20 PM
To: google-a...@googlegroups.com
Subject: Re: [google-appengine] Git Deploy
-A
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
Nick Johnson
Roch--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Nick Johnson, Developer Programs Engineer, App Engine
GordonHo
Brandon Wirtz
It’s just a bit of script… This is from memory, but the logic should hold.
appcfg.py update sandboxapp
//bwcurl is my curl command that I use for firing the test app
//Test app compares expected outputs vs actual output on a long list of functions
// if the test run passes you get a “pass” result
bwcurl http://testversion.testapp.appspot.com/testseries1
Once the Release Manager is satisfied that the First test series has run and is passed sets the default App to the new version in the dashboard, and runs the curl aginst that version. Once satisfied the next script runs
appcfg.py download_app -A sandboxapp -V <application-version> tempapplicationholder
//appnamer does a rename of the app to the LiveLimited Production version
Appnamer predeployment
appcfg.ph update tempapplicationholder
bwcurl http://testversion.predeployment.appspot.com/testseries1
Once the Release Manager is satisfied that the First test series has run and is passed sets the default App to the new version in the dashboard, and runs the curl aginst that version. We bake the release for a few days of realworld traffic then…
appcfg.py download_app -A predeployment -V <application-version> deploymentapplicationholder
//appnamer does a rename of the app to the LiveLimited Production version
Appnamer production
appcfg.ph update deploymentapplicationholder
bwcurl http://testversion.deployment.appspot.com/testseries1
Once the release manager is satisfied it is ready for release they make the app live in the dashboard, run the test pass one more time, and every thing continues on.
The re-download of the deployed code may not seem necessary but it does mean that files don’t sit around for weeks between rounds which is a really crappy security system but it does reduce the chance that what you tested, and what you push forward is the same thing exactly.
From: google-a...@googlegroups.com [mailto:google-a...@googlegroups.com] On Behalf Of GordonHo
Sent: Thursday, November 17, 2011 6:46 PM
To: google-a...@googlegroups.com
Subject: Re: [google-appengine] Git Deploy
hi brandon,
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/c6yfOakb1FwJ.