Advice on techniques for deploying to production

I have a glitch app attached to a live client site. I also have the development version of this app (with new features in development), also on glitch as a different project.

Working on the production, live code in glitch can (and has) caused headaches for the users of the production environment, so I’ve moved to two environments…

To promote my development, work-in-progress version, to the live version, I do this :

  • code and test in the glitch project A
  • export project A to ‘develop’ branch at github.com
  • visit github.com and do a new pull request from ‘develop’ branch to ‘master’
  • go to the live app B at glitch
  • import from ‘master’ branch at github to the production app B at glitch.

This works, and forces me to carefully consider regression tests, database changes and code quality before deploying to production, but it does seem a bit clunky.

Can anyone suggest a cleaner and less manual way to do this ?

thanks --doug

Hi Doug

I was working on a similar workflow as you described, my setup was a glitch project that was cloned from a github repository with a master and development branch which would serve from the master branch, I then remixed the project and then within that project I went into the command console and switched to the development branch by checking it out that would make the glitch project serve from that branch. Which left me with two glitch projects one serving the master branch and the other from the development branch giving both branches a preview version of latest developments and production state.

I would work in the development version and then push to github when I was ready to update the production version. You would then do a pull request on the master branch and pull in the development changes, then from the production version of the glitch project you would pull from github.

I did feel much like yourself that it was getting a bit clunky and switching between projects . Not sure if you have any build step to your workflow. I was using firebase as the final hosting site and my project has a build step which would create a folder to deploy to firebase. Which I would build from the master branch. I found this site netlify which does the build step from github and serves the result from a project-name.netlify.com address. I’m now thinking I can just work from the glitch development branch and have netlify reflect the master branch version and will automatically update when i push and merge the development branch.

I guess that’s my workflow at the moment also using vscode with the glitch extension which works great but having an issue with running high on memory which makes it a bit sluggish. Maybe need a new computer.

not sure if this helps much, still kinda tweaking myself…

Kevin.

1 Like

I have this issue as well. I am working on a production app collaboratively and we’ve been happy with glitch so far but we’re finding the workflow a bit clunky. Our current process, similar to Doug’s, is:

  • we have our main app
  • we each remix this app, do some work and texts on our own remix apps, then one at a time merge this back into the main app manually
  • then we delete our test ‘branch’ remixes

i wish there was a less clunky process. ideally a visual branching version control system. it would also be nice to do something like pull requests but in the process, you can click to see what a hypothetical pull request would like like, and then click to commit to that.

Hi. Old thread but exactly my question! I want to do what you describe but as far as I can see I cannot specify the ‘main’ branch for import to my production app in Glitch. Is there a “branch” option I am not seeing?

Thanks.

At the moment there isn’t a way to change the default git branch. You could try messing around with git in the console, or you could make a feature request as I 100% agree that its a bit annoying pushing a Glitch project to Github and then seeing it was pushed to a different branch.

The code below should work however I don’t know if Glitch’s rewind service will keep committing on the glitch branch.

# use master over main if you prefer
git branch --move glitch main 
git push -u origin main