How do you manage your staging environments?
Hello,
I'm currently building a product to help deploy previews of any application (pullpreview.com), and I'm looking for feedback on how you folks are managing staging environments for your applications.
Is it like one or two dedicated servers somewhere with specific branches deployed? Or maybe no staging environment altogether :) ? Or already using a specific service for that?
What are your main pain points?
Thanks!
Trending on Indie Hackers
i just deploy production code container on stage domain and pass correct env to docker container. once that is setup every time new container is out I just replace the old one. simple
Here, the only two differences between staging and production are the database and Python's virtual environment. Everything else is the very same: one machine, one OS, one storage.
Doesn't help you much for the aim of your product, does it?
I use my own product, Pull Dog for that 😉
https://dogger.io
I know I know ;) One thing I wanted to ask is how do you deal with secrets that might need to be injected into the Compose env?
By the way, do you have Discord or Skype? A more direct way to get in touch? 🙂
Via an API call from people's CI server, and later, an action once that's ready. My action will be thin and just call that said API.
That's how Portainer currently does it when using Pull Dog.
I'm using https://vercel.com/ and they have a smooth Develop. Preview. Ship. cycle. No need to even set up Github Actions. The limitation, however, is that it only works for Vercel itself and a limited number of runtimes. Also, your code has to be designed in a certain way.
I briefly went through pullpreview.com and if I understand correctly it solves a similar problem and more flexible. I'd recommend you to check out how Vercel implements their deployments. Maybe you can borrow some ideas from there.
Vercel has a really nice approach (their team is awesome so no wonder), however they’ve always been limited to JAMstack and even more now that they’ve pivoted to make it the only stack supported. I don’t think there are many differences with PullPreview in terms of behaviour, but I think we offer nice features such as code privacy, no specific config file needed, IP filtering, SSH access etc.
We have hosted our servers on digitalocean so we have two envs right now production and staging, we have separate vpc and servers both both envs.
Deployment is done through gitlab ci, with env variables stored in gitlab itself
We have identical setup on both prod and staging except for the database and services which require persistence.
We also have separate subdomains for staging, for eg: staging1, staging2, most of the time 2-3 are enough, we use ansible playbooks to setup staging environments if needed !
Hope this helps :)
Hi @dezilo, tanks for your reply. Your approach definitely seems like a common one based on my experience. When you have multiple staging envs, how do you target them? Is it based on branch names?
Hey @crohr first of all congrats on HN Launch, saw your post on Hacker News !
Regarding env targeting , Yes we use separate git branches for staging envs, we also have a single primary staging which always has master branch deployed to check bugs on master, rest of the staging envs can have different staging branches depending upon requirement.
You seem to be providing deploy reviews on pullreview, doesn't gitlab provides a similar feature ? how is this different , may i ask ?
Thanks for the reply, and yes HN seems to like it :)
GitLab indeed does provide a similar feature, but it requires significant work to setup and maintain your own servers, provide pretty URLs, etc. And they’re trying to push their k8s integration to make Google happy, which I think is overkill for many teams.
PullPreview provides an integrated solution and works with GitHub, which currently lacks that kind of offering for when you want to deploy on servers you control.
We actually have a GitLab integration on the roadmap, because there is nothing specific to GitHub really. It just happened I had more experience with the API and wanted to push the limits of GitHub actions :)
Thanks again for your insights!
I used to have a
stagebranch deploy set up on Netlify. I would work in that branch and it would auto-deploy when new commits were pushed. Then the default (master) branch had it's own deploy. When I wanted to release and things were good in staging, I would just merge to master and it was all good.I recently switched to Vercel (formerly Zeit Now) and they do this all automatically. Every branch and Pull Request automatically gets built and deployed with a unique preview URL.
In my build scripts, I just have some .env files that will change the firebase project that my static files look for. Right now, my backends are just a few cloud functions so it's not very difficult to keep track of them. But this is the one place where Netlify and Vercel fall short. It's kinda free-form on how you do your backend.
Hi @rywils21, Zeit/Vercel or Netlify are pretty big right now indeed. Last time I checked though it was only for static and JAMstack websites.
I believe there is a gap in the market for something that can deploy any kind of apps. The one-environment per PR / branch is also at the core of what I'm building, and it's a pretty nice workflow indeed :)