Promote glitch app to production

#1

Hello Glitch community :wave:!

I am using Glitch to work on some cool projects, I have an app currently in production tapping into database in production,…

URL is like app-name.glitch.me

I did not want to harm this app while I tried to improve it, so I have remixed original app and called it app-name-staging

Now is time for staging to become production :tada:

What would be your approach for that?

My initial thought was:
on my machine

git clone staging
git pull latest
git push production

Do you think anything against that?
What will happen to my env variables?

Alternative solution, rename original app something else, and rename staging app like original.

Thanks for your help

#2

Hi @picsoung, that’s a really good question!

For the “Community” site (glitch.com) we basically follow your alternative solution; code, code, code; deploy to staging; swap staging and prod. You could use the API to set your project domains and minimize downtime:

curl --request PATCH \
  --url https://api.glitch.com/projects/6335a0be-8306-4fb3-8a22-2fe8e406b240 \
  --header 'authorization: {TOKEN}' \
  --header 'content-type: application/json' \
  --data '{
	"domain": "cori-staging"
}'

renames https://glitch.com/~cori to https://glitch.com/~cori-staging. This will return null when successful, and an appropriate error message otherwise.

You can get your token by opening your browser’s dev tools, opening the console, and examining localStorage.cachedUser and looking for the persistentToken property. JSON.parse(localStorage.cachedUser).persistentToken should get it for you. Do not share that token anywhere - it allows anyone who has it to act as you on Glitch.

Hope this helps!
cori

#3

Thanks @cori!

That looks great :slight_smile:

Any suggestion on how to swap env variables between staging and prod?

Thanks

#5

Hey @picsoung that’s something we don’t run into in our own work on the Glitch homepage, but there are a number of approaches you could take.

One might be to have two files, .env and .env-staging with their appropriate info. After your swap you could rename them as needed and refresh the app to pick up the change - all of that could be accomplished in a shell script you executed from the console, or you could set up an endpoint that you call after you’ve done the rename that uses Node’s built-in fs.renameSync or something along those lines (although I’d want to protect that endpoint with some sort of secret to make sure it doesn’t get hit by some random internet person).

If you don’t want to manage files that way (and by some gauges that’s an anti-pattern best to be avoided) you could also use something like https://www.npmjs.com/package/update-dotenv to update your .env file.

Regardless of which way you go, it would probably be a good idea to maintain your secret info inside your project’s .data directory, where it won’t be committed to the git repo and won’t be included in any potential Remixes.

Hope that helps!