Rollback your Google Cloud Function to its previous version

Photo by Testalize.me on Unsplash

Google Cloud Functions is a serverless execution environment letting users to run their code in 7 different languages with multiple versions of the language runtimes. It is flexible, scalable, reliable and can be used for a variety of tasks including running production workflow steps, DevOps and Operation tasks, security validations and more. Like with other providers it implements “pay as you use” principle without hidden costs (reverence to some other cloud providers that provision and bill you for extra services).

It is almost perfect (yes, I work for Google and love Google Cloud) with few minor drawbacks. The one I recently came across is an ability to rollback to the previously deployed version quickly and without a need to go through the deployment process. After searching I found an answer at StackOverflow that leverages the way how Cloud Function stores its deployment artifacts. First, a quick recap about the method.

When deploying Cloud Function, the artifacts are zip’ed into archive and the archive is stored into a specialized Cloud Storage bucket in the same project where the function’s instance is deployed. The bucket can be found by its name. For Cloud Functions of the Generation 1 the name will look like

and for Generation 2, it will be

where the [PROJECT_NUMBER] denotes the unique Google Cloud project number where the function is deployed and [LOCATION] is the region where the function is deployed.

Inside the bucket you find folders with function artifacts where the folder’s name starts with the function name following the unique id (in GUID format) of the function’s resource for Generation 1 functions or is just the name of the function for Generation 2 functions.

The solution on StakeOverlfow describes the rollback for Generation 1 functions. The following bash script uses Google CLI to do the same work:

FUNCTION_NAME="place-your-function-name-here"
PROJECT_ID="place-your-project-id-here"
PROJECT_NUM=$(gcloud projects describe $PROJECT_ID \
  --format="value(project_number)")
VERSION_NUM=$(gcloud functions describe --project=leoy-toolbox \
  $FUNCTION_NAME --format="value(version_id)")
BUILD_NUM=$(gcloud functions describe --project=leoy-toolbox \
  $FUNCTION_NAME --format="value(build_id)")
LOCATION=$(gcloud functions describe --project=leoy-toolbox \
  $FUNCTION_NAME --format="value(name)") | awk -F/ '{ print $4 }')
SOURCE=$(gsutil --p=$PROJECT_ID ls \
  gs://gcf-sources-$PROJECT_NUM-$LOCATION/$FUNCTION_NAME* \
  | grep -v "version-$VERSION_NUM" | tail -1)
gcloud functions deploy --project=$PROJECT_ID $FUNCTION_NAME \
  --source=$SOURCE/function-source.zip \
  --region=$LOCATION

The script uses known project id and function name to retrieve other information such as the project number, the function’s location, latest version and the path to the previous version’s artifact. Then it uses the URI to the artifact to deploy it.

NOTE: The previous version in this case means just to select one out of two folders which name does not end to the version id of the currently deployed version.

However, this will work with one important limitation. IF the following deployment sequence took place, the rollback artifact will contain the invalid deployment code/configuration and not the “last working version, before the current successful deploy”.

It happens because Generation 1 Cloud Functions artifacts seem to store only two last versions regardless of the success status.

The situation is much better with Generation 2 Cloud Functions. For them the folder with the function’s name stores function-source.zip file with enabled history feature. So, theoretically you are able to rollback to the “last good” version. However, due to the lack of any indication which previous version was “good”, it can be a tricky business.

Summing up, it IS POSSIBLE to rollback a previously deployed version of Cloud Function without working vs. source code management system. However, the feature leverages undocumented method of storing Cloud Functions artifacts and is not ready for use in production workflows.

Spoiler: There is “Work-In-Progress” to support this functionality for Generation 2 Cloud Functions. Without making promisses it is reasonable to expect it in 23'H1 🤞