Is there some sort of ‘staging environment’ or similar, where we can essentially keep improving our internal CODA documents, without interrupting the live documents, and to then push such releases or updates?
If not, I think this would be a mission critical feature in order to adopt coda at scale.
hi @Anthony_Hsiao , as far as I know, this is not available. More coda makers have asked for this in the past, certainly after updates that caused some trouble.
I do very well understand your need and since this feature is not (yet) there, I stick to functions that are ‘official’ and second I keep the design of the docs as simple as possible because I fear that all the fancy work might be broken one day.
Looking forward for responses from other makers.
i agree that my corporate clients would appreciate this.
at present we use different workspaces for dev, test, pre-prod and production.
the FIRST thing i always do in a new document is to add a BUTTON that does a CopyDoc() so we can easily create a new ‘version’ before making major changes. so we add “v1.x” to the end of document names, and increment for each major change. we also create a CHANGELOG page (hidden) to record the changes made for each version. we then use COMMENTS to record bugs and change requests etc.
its far from full dev-ops but it works for us and is understood by IT folks in our corporate clients.
it has just occured to me that this CopyDoc() button could ALSO record the ID of the person making the copy and ask for a short narrative about the new version… hmm.
max
We do this as well, but I’ve also taken it to a new level with a custom pack. Purely for test and dev purposes, I’ve started tracking a number of activities with a Trackify() pack - it basically allows us to quickly insert logging events for Copy Doc and a variety of other activities. This helps us capture data about uses and row changes in critical tables. In some cases, rules trigger Trackify() events which then use the Coda API to log all of the actions to a common [Coda] table.
Surprisingly, I tested such a Trackify() inline instrumentation in a page using the Now() formula for the time parameter and it started tracking page presence for each user. I wasn’t expecting this surprise and I’m not sure this is wise because of the massive number of hits as users languish on a page. But, if you aggregate the hits into event counts for each document/page/user you start to see data not that unlike Google Analytics - you can even determine time on page with a little computational effort.
Hi Anthony, and welcome to the community!
I tend to agree. However, let’s not forget that Word and Excel were both adopted at [global] scale without any DevOps capability. Certainly, Coda is at a programmable flight-level far higher that these tools, but poor development and change management policies are tolerated by millions of companies to this day by the vast Microsoft enterprise adopters.
I think you’re factually correct, but please note that MS Office applications were also not real time collaborative features. If it was just me / my local file, I wouldn’t need it, but if we have departments running their daily business process on Coda - essentially applications - then it’s very hard to make changes that may break the system(s)
Correct, but how many Microsoft Office users compensated for staging and deployment by making copies and naming them appropriately to overcome the lack of an underlying change management system? Almost every one of us did this from 1996 until, well - yesterday. 
We can certainly agree that this is as mission-critical today as it was then. But, global scale adoption of Office documents occurred before and after the advent of web-based live documents in (which first appeared in 2008 in SharePoint) and Office 365 which began in 2010.
Neither client-side nor web-based Office apps ever supported a comprehensive staging capability and to this day, the brittleness in Office 365 documents exists just as it does in Google Workspaces. Like Coda documents, there are ways to lessen the likelihood of disaster, but it’s still possible to change something and force all users to endure the crisis that may unfold when errors strike.
In Coda (at my company), we struggle with deep-links; our users like to reference their Coda resources in other platforms (Slack for example) which are tantamount to bookmarks frozen in time. This places added pressure on Coda makers to formulate processes that move new development and test to a replica of the document if – and only if – the document is “mission-critical”. This, of course is more costly because it requires a tedious deployment process or the risk of losing the connectedness with the user’s community of known links. One way we overcome this is GoLinks - still tedious though.
As improvements to Coda workspaces emerge, this has become less of an issue because users are seeing the workspace as the authoritative access point for their documents and this allows us to fully replace v1.1 with v1.2 all while developing and testing in parallel documents.
@Agile_Dynamics I’m now experiencing the issue that this thread talks about. Unfortunately my business scenario is quite complex so the idea of keeping things simple is difficult.
Live documents tend to contain data so how do you get around the fact that data then needs to be brought into whichever version is being used.
Do you copy it all each time or accept data loss?
One method I am thinking of is to create a new page for every different version and use connected views. However, this does not get around the fact that there could be breaking changes to underlying tables.
Any tips would be most appreciated.
Never mind @Agile_Dynamics, I just read your advice on this topic in this thread:
@maria this would be a great Coda Best Practices webinar topic 