Deploy easily with the new Google Apps Script IDE
By: Romain Vialard
Tags: Deployment, Google Apps Script, Version Control

A week ago Google announced the availability of an improved code editor for Google Apps Script. (note: this new editor isn’t yet available to all — it should be by the end of the year🤞). In this article, I’ll focus on the changes related to Versions and Deployments in Apps Script.

Depending on your needs, you can deploy your Apps Script code in many ways:

The new IDE makes deploying your code one of the primary actions, with the blue “Deploy” button quite visible in the UI.

In most cases, you will deploy your script in only 1 of the 4 ways listed above but it can be useful to deploy a script in multiple ways and the new UI lets you do that (eg: you could deploy your script as a Web app — for humans — and as an API — to let other programs exchange data with your app).

This is a slight change compared to what was available in the old UI. You could also deploy a script as a Web app and as an API but they were considered as 2 different deployments of your code and when you wanted to publish a new version of your code, you had to update those 2 deployments.

It added extra complexity without real benefit and the new UI greatly simplify that. BUT if you happened to like having several deployments all tight to different versions of your script, it’s still possible (see doc).

What’s happening to versions?

When an update is ready to go live, simply make a new Deployment. It will create a new version of your code behind the scene and push it to your users (note: that’s not true for old add-ons, for which the version number still have to be updated in the Marketplace SDK). Of course, making a new deployment won’t affect your web app url, API or Library ID — it will remain the same 👍.

⚠️ note: as of 12/14/20 — this is only true if you first publish your script from the new IDE. For existing scripts, deploying from the new IDE will create a new deployment with a different url for your web app (see this forum thread).

Making a new deployment creates a new version and the previous deployment, tight to a previous version, is archived. When clicking on “Manage deployments”, you can find the list of all archived deployments corresponding to all previous versions of your script.

The Description field of a deployment in the new IDE matches the Description field of a version in the old IDE.

As before with versions, the Description field is not mandatory but will default to “Untitled”. A new reason to always add a description for each new deployment / version 😋.

The left sidebar is filled with “Untitled” because I didn’t added a description on my deployments / versions.

A little bit of history

Playing with Google Apps Script since more than 10 years now, I thought it could be interesting to make a recap of the evolution of Apps Script deployments over the years.

The first way of publishing a script, as a web app, was made available before Versions existed. It was called “Publish as service” and each update of your code was directly available to all users 😱.

Then Google added the ability to share scripts as reusable libraries along with the ability to create versions of your code. Not long after that, versions were also made available when deploying your script as a web app — a greatly appreciated evolution!

Add-ons made their first appearance in march 2014 and came with versioning right away, a great move as add-ons made scripts available to a way bigger audience.

In 2015, Google launched a new framework to build add-ons, starting with Gmail and along with that came the notions of Deployments and the project Manifest.

This meant that we had a menu to manage versions, another one to manage deployments + different UIs depending on how you wanted to publish your script (web app, API, add-on). The new IDE mixes all that into a single UI, making easier for all to deploy a script while keeping all the features made available along the years.