191
Service Groups in the Dashboard
complete
Log In
M
Meagan Gamache
complete
As of today, projects are now available to all Render users on the team plan or higher. Learn more on our blog here: render.com/blog/projects
E
Emile
Please consider the network isolation (https://feedback.render.com/features/p/network-isolation) in your implementation. Offering environments that are not segmented is really not the way to go and is against all modern good practices of security.
The docs makes it look like it is a good thing and should be rephrased as a SEVERE limitation front and center.
Anurag Goel
Emile: I agree network isolation within teams is an important feature, and we've added it to our near-term roadmap.
S
Shawn Moore
Projects is now in Early Access! Use projects to organize the services for your applications, and environments to manage multiple different deployments (think Production vs Staging). You can try it out for your team by enabling the feature in your team settings.
More information on projects in our docs here: https://render.com/docs/projects
M
Michael Hellein
Shawn Moore: I appreciate that there's a way to group services, but this seems like it's both too much and too little. It's too much UI and navigation for something this conceptually simple, and it delivers too little functionality for the level of setup it requires.
For this feature, I would have been happy to have a way to tag services and filter them on the dashboard. This feature isn't a great fit for the stated need from this discussion.
What I really want from "projects" is a pipeline for (atomic) releases, and this seems like a step away from that instead of toward it, since it encourages plopping more than one resource into a project's environment sack. It seems that customers are looking for a replacement for Heroku's pipelines - or even a clone if the product design process doesn't come up with something more intuitive.
D
David
Michael Hellein: Exactly, I can't agree more. I think Render made a design mistake when they decided there was no need to distinct build phase from release phase, as stated in the 12-factors-app manifesto. I wrote a detailed article to explain why: https://www.david-dahan.com/blog/the-importance-of-the-release-stage-in-deployment
S
Shawn Moore
Michael Hellein: Hi Michael, thanks for your thoughtful note. We certainly hear you that you'd like more from projects. What we're launching now is foundational for the features you've mentioned, and even more still that we're excited about, like network isolation between environments. This first release was designed very much with that ambitious roadmap in mind.
We're always happy to chat more about what you're looking for - shawn@render.com.
S
Shawn Moore
David: Hi David, expect to hear more about decoupling builds from deploys soon!
J
Julian Vergel de Dios
David: Strong agreement with your article. The separation of build and release phases in Heroku that enabled the pipelines feature was so central to what made it a joy to use for non-trivial apps, IMO, but no one seems to be trying to replicate it (except hopefully Render, now).
Anurag Goel
in progress
T
Tushar Ranka
Anurag Goel: Is there any update to this much awaited feature?
Anurag Goel
Tushar Ranka: we'll have a big update today/tomorrow
Anurag Goel
M
Michael Hellein
Is the in progress Render concept of service grouping going to include build promotion? To me, that's the most crucial missing feature in Render. The fact that there's no way to do an atomic deploy of an existing tested build introduces risk into every release (or even a change to environment variables).
Anurag Goel
Michael Hellein: not in the first iteration (which will be out in a few weeks), but definitely after.
M
Michael Hellein
Anurag Goel: That's great news, on both counts. Thanks!
J
Jeremy Bell
I would love the ability to pause/resume multiple services at once
W
Wojciech Rzepecki
Hey Anurag Goel, any progress news about this feature?
S
Shawn Moore
Wojciech Rzepecki: Hi Wojciech, we should have some exciting news before the end of the month! :)
S
Shawn Moore
Give us one more week or two to polish!
b
barry
My case is fairly simple, and when I think grouping I think deployment.
My Blueprint encapsulates a number of things including a Rails web service and a Sidekiq worker service. As the web and worker services need to stay in sync codewise, I would like a way to mutually deploy both of those services together. I realize auto-deploying might approximate this, but I’d prefer not to auto-deploy and it also doesn’t assure that both services have successfully deployed before finalizing the deploy. It would be good for these deployments to be tied together such that they can be rolled back together if either of them fail.
B
Bergur Hallgrimsson
I would love the ability to link the blueprints to those groups. Today the "standard solution" to having staging with autoDeploy and preview on MR and then a manual deploy is duplicate the blueprint and move the production blueprint into a another repo.
Load More
→