Is there a thread about rolling out a Glide App and maintaining it (best practices, etc?)
I expect that when this App is rolled out I will move it to Enterprise so I get support but dev will stay under the Pro plan. I have no idea if this is a preferred way to do this or, frankly, any best practices on how to roll-out and manage Glide Apps.
Any details/pointers/thoughts/missives are VERY appreciated.
I’m not sure I follow on this. An app stays within a team. If you upgrade the team to Enterprise, then all published apps within that team are enterprise apps. You would still develop the app within that enterprise team. I’m not sure what you mean when you say that dev would stay under the pro plan. That means you would have to move the app to a team that only has a pro plan, but then it’s only a pro app.
It sounds like you want a dev environment and a production environment, can you confirm?
The best practice for development after rolling out is to turn off auto publishing. Whatever your app’s plan is on should be aligned with your usage.
Yes - the vision is the application will be continuously in DEV but a version will be PROD. PROD will have bug fixes but basically stable until a new version is rolled out. My App imports data from Excel/Sheets and soon Airtable and that production data will only be accessible in PROD. Most developers would not have access to PROD data.
Developers would work mostly in DEV (sandbox) with PROD have more limited and protected access. Plus data privacy rules will limit/track everyone who has PROD data access. I don’t need that in DEV.
Hope this makes sense
In short, Glide is not a traditional dev environment.
At my day job, we have Dev, Test, and Prod environments, and likewise there are Dev, Test, and Prod databases. I work with a DB2 database on a mainframe, as well as SQL Server on some of our windows servers. On top of that we have mainframe applications as well as web and PC applications that use that same database. In the applications, it’s easy to switch out which database you are pointing to, because it’s as simple as changing a library list, or changing a database connection. Also, as expected, we promoted applications through each environment until they get to production…and each environment points to it’s respective database.
I’m well aware of a traditional development environment, but Glide doesn’t exactly work that traditional way, and it’s important to grasp that. Glide does not have separate environments. But, like @ThinhDinh said, you can turn auto publishing off and control when user interface changes are published. Data on the other hand is a different story. Data in glide in much more ingrained into the app. It’s not like traditional development where you can determine your database connection separately when the app is ran. Instead, it’s like the data is the app, with a UI skin on top of it.
While you can control publishing of changes to the UI, the data itself is always live. Any changes to data, changes to the layout or formatting of data, or removing columns will most definitely affect a live app, even if you have publishing turned off. With glide, you can’t simply switch out a database at will. There is only one connection to data and it’s essentially permanent. It’s not as simple as changing out a database connection. I mean, you can, but it’s a lot of work and really depends on your data sources. You could change out tables, but you may also be rebuilding screens to connect to those different database tables. The whole glide interface is deeply connected to table ID’s and table header ID’s. That’s why you can change a table name or change a column header name, and it’s updated everywhere in your app, unlike a traditional dev environment where you would probably have to update a bunch of SQL to match new and updated columns or table names.
If you really wanted, you could duplicate an app, as well as all of the data, and then make your changes to that duplicate copy of the app, but then switching out apps when you are ready for production would involve switching out urls, custom domains, and manually updating data in your duplicated tables so it matches the current live data. It becomes a whole lot of work.
My recommendation would be to turn off auto publishing. Make your changes, and when you are ready for production, publish the changes. If you do anything with data, be VERY mindful of what you are changing. Like I said, data is always live. There is no dev or test version of data. If you need to, make duplicates of columns for the new interface changes to use, while leaving existing column undisturbed for the live version of the app.
Personally I just make my changes in live. If they are minor changes, I just go ahead and do it. If it’s something more substantial, I may add a new screen or tab with the visibility set so only I can see it. Then I can still play with the published app on my phone to test things out. But my user base is two people and I’m dating one of them, so it’s not so crucial if someone sees something while I’m in the middle of making changes. 
Overall, Glide is just different and sometimes you need to switch off your traditional programming brain to understand how glide works for non-programmers who may not understand that way of thinking. Maybe someday Glide will build a more robust development environment with different environment capability, but I don’t see it coming anytime soon though, because I imagine it would be a massive undertaking to take glide to that level of development control.
I do this for one of my clients. They insist on being able to test new features in a “staging” app before anything goes live. So I developed and documented my own process for managing this. This is what it looks like:
It’s fiddly, and the switchover process is fully manual. Usually takes me about 30-60 mins to deploy a new “production” version.
Teams are not designed to be used as folders–if you have a workflow that relies on moving apps between teams, we don’t recommend that.
Teams usually correspond to companies.
The “workflow” is best practice for deploying a Glide App. The production App has customer private data that developers should not, in a normal basis, have access to from a privacy perspective.
Having to maintain two “Teams” to maintain this privacy separation appears to be one option.
Looking for other thoughts/ideas/options.
Thanks
At my job, all developers have access to production data. In many cases we need to see production data so we can work with real world examples of data and real world scenarios for debugging. In my industry, there are just too many unique scenarios that would be hard to accurately reproduce in a test environment. We have a simple solution that copies data from one environment to another, so we can test with that real world data very easily, fix a problem, and deploy the fix quickly. Customers also often ask for lists of affected items after a fix has been deployed. This also requires us to access that production data to create the list. All developers and support staff need access to production data to adequately support our customers.
Due to those circumstances, we sign yearly NDA’s and Conflict of Interest forms, along with yearly compliance training to remain compliant with company, customer, government, and SOC audits.
In my opinion, developers should be trusted in the first place, whether they are doing the development, or working with the data. I realize that’s not the case for every company and every product, but that’s how it is where I work. We create the software, we host and serve the software, we host the data, we support the customers, and we provide additional services to the customers.
This isn’t meant to sway either way. Just wanted to share my personal experience and thoughts.
