Hi Community! It has surprised me, bringing a Workspace add-on to the market that I have had to employ a number of work-arounds to bring good practice to DevOps and Add-On development. Anyone else?
I need to use `clasp` and maintain a disconnected git branch to effectively manage versioning, and CI,CD is practically unmanaged.
Would be happy to share exactly how we run a Gold and Silver build so that our team can confidently demo code, while others work on sprints… but good to hear what everyone else is doing?
Thanks, that’s new to me so will take a look…
Depends on how portable and complex you want to get. I’ve had quite a bit of success using ArgoCD an Argo Workflows for DevOps and manifest promotion. Sensors can monitor whatever branch you like and you can build in whatever tenancy or promotion/rollback models you want using Helm charts/Kustomise.
Yes, this is all K8s based, but most systems are these days :)
There are in fact some hoops to jump through when publishing a Google Workspace add-on to the Google Workspace Marketplace.
Currently, the Apps Script editor doesn’t allow versioning like most developers would like. So working with clasp and GitHub is the only workaround.
From what I’ve heard, lots of developers work with the built in script editor which allows for two versions: the productive one (Head) and a test version. But this means that the code isn’t in a repo and no code reviews through a tool like GitHub can be made.
This article by a Google Developer Expert might be interesting for further insight: https://workspace.google.com/blog/developers-practitioners/customize-google-workspace-with-add-ons
Thanks for your help
We use clasp to create a version tag (so Monday has a Gold build at the end of the day, which has passed QA - this is the stable release that folks can use for testing, and is a candidate for an updated Marketplace push) and devs can carry on work with what we call the Silver build which is not passed QA.
Using clasp version and deploy commands solves the Workspace issue, and then we check the diff from a clasp pull, comment the code with the accepted changes and the commit and git push to our code repo.
As I started in my question, this is a significant work around.