11

It takes so long to deploy an app to App Engine by this command

gcloud app deploy

After I updated my source code, even if it's just one line of change, I had to issue this command again to upload the changes to App Engine. Again it will take a long time to deploy for just one line of code change. Is there a way to quickly update the code on App Engine instead of doing this time consuming deploy again?

I am looking for options that can speed up the code update after it's first deployment to App Engine. Since I am using flex, would using standard make it faster to update the code? Is it true that there is no way around it on App Engine and the only way to do it is to use another service such as Compute Engine?

wescpy
  • 10,689
  • 3
  • 54
  • 53
s-hunter
  • 24,172
  • 16
  • 88
  • 130
  • standard or flex env? – Dan Cornilescu Oct 02 '17 at 16:09
  • It's a flex env – s-hunter Oct 02 '17 at 16:15
  • 1
    Possible duplicate of [Google cloud deploy so slow](https://stackoverflow.com/questions/40200467/google-cloud-deploy-so-slow) – Dan Cornilescu Oct 02 '17 at 16:28
  • I've added some more thoughts to the question. I agree it's somewhere similar to the other post, but it's not a duplicate. It could take me another hour to find that post, and the answer from that post explained why it's slow but no answers as to how to speed it up. – s-hunter Oct 02 '17 at 16:38
  • Given that Flex's application code should operate more or less the same locally (assuming single instance), why are you deploying for small changes with the hope of testing in more of a production-like environment (even if used for staging)? What language runtime are you using? – BrettJ Oct 03 '17 at 05:18
  • It's Node.js. I was going through this tutorial Authenticate your Firebase users with Instagram https://firebase.googleblog.com/2016/10/authenticate-your-firebase-users-with.html – s-hunter Oct 03 '17 at 15:25

2 Answers2

1

Yes, standard env app deployment in such context is much faster, because it only involves uploading the modified files and restarting the instances.

But using standard env is often not an option for other reasons. The potential duplicate post I referenced contains itself references to both explanations and suggestions for potential speed improvements. I don't see a point in duplicating them.

The most common reasons for choosing flex env:

  • language support
  • restrictions of the standard env sandbox

See also: Google App Engine Standard or Flexible environment?

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • It would be nice if you can elaborate a little bit more on using standard env is often not an option for other reason. – s-hunter Oct 02 '17 at 18:46
1

(Sep 2021): First of all, the issue you describe for App Engine (flexible) does not apply to App Engine (standard), which is almost a completely different product. (For those who are new, here is a comparison b/w both products.) This question is a few years old, and there are a few more options available to you now:

  1. App Engine standard: If your app can run in Python 3.7+, Java 11, Go 1.12+, PHP 7, Node.js 10+, or Ruby 2.5+, then this is the obvious place to go. A deploy should take less than 1 minute.
  2. Cloud Functions: If you don't have an entire app or your app is made up of one function/route or is otherwise short & simple, consider turning it into a microservice for Cloud Functions. Its deployment time is also less than a minute.
  3. Cloud Run: If you're using App Engine flexible because your app is containerized, consider Cloud Run, which runs containers in a serverless way. A big bonus is that a Dockerfile is optional (due to Cloud Buildpacks). It has taken many GAE flexible use cases. Deployment is also less than a minute. If interested, I produced a pair of videos on how to migrate from App Engine standard to Cloud Run, using Docker as well as no Docker. At some point, I'll do one on transitioning from GAE flexible.
  4. App Engine flexible: If none of the options above work, requiring you to stay on GAE flexible, then yes, you'll have to deal with its longer deployment time (due to the complexities of the system and all the resources it needs to spin-up & manage on your behalf). If you have a container and Cloud Run isn't an option, also consider GKE Autopilot or GCE MIGs (managed [VM] instance groups).
wescpy
  • 10,689
  • 3
  • 54
  • 53