jeremy_k

Yes, Buildkit allows for this with the `--mount=type=cache` functionality. [0]'

Now as an end user you still have to add this to your Dockerfile, but if subsequent builds are able to continually use this cache, build times will drastically improve.

- [0] https://docs.docker.com/build/cache/

I replied to a sibling comment with a list of a few. https://news.ycombinator.com/item?id=34166459

https://releasehub.com/ (Disclaimer, first listed because I work here)

https://www.quali.com/

https://www.withcoherence.com/

https://webapp.io/

https://www.uffizzi.com/

https://www.qovery.com/

https://www.devzero.io/

These exist in the B2B space (and isn't an exhaustive list), there are a ton more in the B2C space

I 100% agree with your second point. Case in point, my previous employer built an in house development platform to create ephemeral environments and run deployment pipelines for production. At the time, around 2016, there weren't many (or any? I wasn't part of the research time) options to buy this type of software. Today, there are more than a handful in this space.

I wonder at what point companies would finally bite the bullet and swap to buying? Maybe cataloging the feature set of the internal software, seeing what is a necessity, and seeing which vendors can cover those requirements?

Sounds like a large dependency graph and multiple variants of spinning up the environments.

I'll try to simplify what I mean by that but something akin to having Services A, B, and C.

Each of A, B, and C need their own definitions to define how they need to be spun up as well as a definition on how to populate their data. That data population, say through RDS, needs to be spin up RDS instances and make them ready and available whenever someone creates a corresponding ephemeral version of a service. Toss the database afterwards.

In the above case, assuming you needed a full graph, you would spin up the three services as well as attach each service to its corresponding database. This approach works well when the number of services remains small.

Once that number starts growing, it may not be cost effective to spin everything up. Say service N is needed, but you really only need to read from it. In this case, you might have a dedicated staging environment for N and create a dependency graph that says "in my ephemeral environment, create new instances of A, B, and C with their databases, but also allow network requests to make their way to N."

That might be over simplifying, but I've been working in this space for the past few years and have been thinking about this exact issue recently

You're 100% correct that the target audience of this isn't HN readers. Having worked in this space for a number of years and having written this same fluff article in 2020, this type of content is marketed directly to engineering managers and VP types who are looking for solutions to issues around their SDLC or developer productivity.

The technical implementation part can be interesting to readers and potential engineers who will use the platform and is worthwhile to have available, but this content is purely meant to cast a wide net.

Thanks for the update! I passed the information along to the our Customer Support team.

Any thoughts on building a widget for on-site issues? I could see our company adopting this right away as we're heavy users of Slack connect to interface with our customers. We migrated from Intercom to FreshDesk and our current workflow in Slack is very reactive where a customer brings up an issue and a ticket is created later. However we do still get some tickets created from the on-site widget and it might be a non-starter to migrate without that functionality.

Thought it was interesting to see Vercel launching this feature as I recalled a previous YC Company, FeaturePeek, had been purchased by Netlify [0]

- [0] https://techcrunch.com/2021/05/19/netflify-snags-yc-alum-fea...

Disclaimer: I work for the company which wrote the blog post.

We basically do this at ReleaseHub, however there is a level of indirection we introduced. We basically have our own version of Kompose which generates our own YAML file, which we call an Application Template[1]. The Application Template then gets parsed into Kubernetes YAML and deployed, however as an end user, you never have you deal with the Kubernetes YAML.

The main piece missing is that we set everything up to parse the docker-compose file once and then expect people to interact with our YAML. However, having seen the level of interest about compose in this thread I'm wondering if maybe there is a feature to be built where we remove the need for interacting with our YAML, an end user can push changes to their compose and through GitOps we update everything and deploy new changes to Kubernetes.

The compose spec has come a long way since we started (we were attending the spec meetings back in 2020 to see how the project was going to kick off) and is in an even better place to support this direct Compose -> Kubernetes idea.

If you're curious, feel free to reach out jeremy@releasehub.com.

[1] - https://docs.releasehub.com/reference-documentation/applicat...

When you say 'a kubernetes distro that can be managed entirely using compose files will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....'

Do you mean from the your perspective, you set up your docker-compose and this startup ends up deploying pods into Kubernetes based on your compose file? Basically cutting out the middleman of you having to deal with Kubernetes yaml files?

Interestingly enough I have found Twitter's recommended tweets and showing me tweets that people I follow liked as an added benefit. I've started following many different people across tech with different view points and I feel that is a positive. The caveat to all this is that I don't know / haven't met any of these people in real life.

On Instagram I mostly follow my friends, I want to know what they're up to. My usage of Instagram dropped off the map once my feed turned into - Friends Post - Friends Post - Ad - Friends Post - Suggested Post - Ad

It really just feels like the content I want to see is being smothered and thus I've mostly stopped using Instagram.

It is probably a huge leap to think about using Bazel, but I found Uber's blog post about how they manage this issue after setting up a monorepo a really good read - https://eng.uber.com/go-monorepo-bazel/

To note, we signed up for the beta and got accepted in last week. Haven't turned it on yet though.

Do you work in game development? I would love to hear a little bit more about your experience. I play and follow Apex Legends and I'm always so curious about how bugs and regressions seem to make it into every one of their patches. As well as tons of new information that gets data-mined.

To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch) and they don't have unit tests that catch bugs (a certain ability has 2 modes, with 2 different activation times. In the most recent patch, the activation times ended up the same) but it's possible that developing a game is far different than developing a SaaS product from a coding perspective. Or it could be that studio just has weird practices.

"It’s okay if you don’t have a lot of context on a pull request. Try to contribute one useful thing. One of the best ways is to check it out locally and take the feature for a test run!"

Since I work in the space I'm biased, but having to pull someone else's code locally to test out their feature is such a non-starter for me. If your company is in hyper growth mode (or even if it isn't) and the engineers don't have their own dev environment or better yet an ephemeral dev environment to allow others to test run the code, the company is hampering their product velocity.

The surprise meeting at noon just got spoiled! Congrats to the Temporal team. We're just getting up and running with Temporal at Release, but I'm very excited to see the effect it is going to have on how we design and interact with our code.

Interesting that both Periscope and Meerkat eventually got bought out and shut down. It seems like live content may not be as sought after, but I would say we're seeing a 2.0 attempt of both apps with Clubhouse.

It's called Backdoor Roth Contribution [1]. It only really works if you don't have any normal IRA accounts.

1 - https://www.investopedia.com/terms/b/backdoor-roth-ira.asp

Definitely going to check this out. Our company was just discussing how we wanted to go about coming up with some new designs for the app without a full time designer on board.

Just to note, after I used the invite feature, the pop out closed, but when I re-opened it, the email was still in the field.

Thank you for the kind words. I'll try to answer what I can!

In regards to the customers needing an ops pipeline to create images, that isn't necessary to use Release. We have our own build infrastructure, running on Docker Buildx so we can take your code, turn it into container images and deploy it without you needing to have anything set up yourself aside from a working Dockerfile.

But there may be customers who do already have their own pipeline setup running tests and creating images so we did create an external API for shipping those images to us [1]. Creating full fledged integrations with other service providers is something we've thought of exploring, but for now it would be possible to create an environment via a POST call with the image information and a bit of pre-setup to make sure we can pull the images from where you've stored them.

What you describe in (b) is definitely possible right now. The `git push` will send the webhook to us, we'll create the image and automatically deploy the environment. What you describe in (a) is also something we think is important. We have an integration with LaunchDarkly [2] that has pre and post deployment hooks so building out features around those type of hooks for different use cases is something we want to lean into. Another example in the (b) category is our Instant Datasets [3] which gives you an RDS instance with pre-filled data to be used for say a sales demo or a QA validation.

[1] - https://docs.releasehub.com/api-documentation/release-api/cr... [2] - https://docs.releasehub.com/integrations/integrations-overvi... [3] - https://docs.releasehub.com/reference-guide/instant-datasets

Hi, I built out our microservices solution and you read more about it in the Microservices Architecture documentation [1]. There is also a walk through of setting up two applications with this approach in the documentation [2].

At a high level, the way ReleaseHub solves this issue is through a feature we call App Imports. Each App would be microservice and there would be one application that imports all the others. For the sake of simplicity let's have two microservices, Frontend and Backend. Frontend would import Backend and when a deployment goes out, ReleaseHub would deploy Backend first, followed by Frontend. Both deployments end up in the same Kubernetes namespace so the pods can talk to each other directly.

This setup allows for creating the dependencies needed to run the services. If you wanted to set up Backend to only deploy itself and say run integration tests against it, you don't have to connect it to any other services. But Frontend may be useless without Backend, so hooking them together is a requirement.

[1] - https://docs.releasehub.com/getting-started/common-setup-exa... [2] - https://docs.releasehub.com/examples/app-imports-connecting-...

We tried this approach and have attempted to bend React Context to our need, but it feels like its gotten pretty hacky. Are you only using component state and Context or what is your approach?

Gatsby + Github pages. I run `yarn deploy` and it publishes the built version of the Gatsby app to the `published` branch and Github automatically updates. The `main` branch of the repo remains intact for editing content.

Interesting to see this come up. I wrote about using pass to authenticate to Docker inside of an alpine linux docker container last summer[1]. It was quite the undertaking to get it all working. The premise was to figure out how to securely log authenticate to docker, potentially in a CI type system.

[1] - https://jer-k.github.io/apline-linux-docker-authentication-w...

Who are these engineers that would have built these free libraries?

Yep, just crashed for me too

> a statically typed Ruby clone

Could be that. I've used Ruby for 10 years, I'm just used a dynamic language. I also dealt with a typed Javascript monorepo and it was not very fun to deal with when the types weren't working for whatever reason.

I guess it depends on the programmer. I've fallen in love with more functional style of coding. The idea of data in and data out makes me feel like it's so much easier to follow what is going on compared to having objects with side effects and mix ins and instance variables. I try to write as much of my Ruby / Rails avoiding the things I mentioned, but its pretty hard to avoid in a larger codebase.

My completely biased answer is I haven't written Java since I was a freshman in college (2009) and that was like a few months. I basically know nothing about the ecosystem.

I've written Rails professionally for almost 10 years and have been following / playing with Elixir since 2016. While Ruby / Rails are amazing and the ecosystem is well suited getting a project off the ground extremely quickly, I'm just a big Elixir fan and hope to work with it professionally one day. I'll parrot reasoning from some of the sister comments.

"having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition." - Very tempting indeed!

"Code elegance and development joy, maybe?" - Coming from Ruby / Rails, I agree 100%

"Not being statically typed" - Again, I've worked mainly in dynamically typed languages. I've experienced typing in Javascript and wasn't the biggest fan. But don't get me wrong, Rails can be awful when trying to dig multiple objects deep to understand what the data structure of the return value is so its not completely off the hook.