Re:Launch HN: LayerCI (YC S20) - Staging servers that act li...
by colinchartier on Sunday January 31, 2021 @02:19PM
(#25981626)
> In particular, the 'correct way to solve this problem is to stand up an environment for your PR and structure your CI so you only re-run the parts that affect the particular change you want to make, rather than re-running the entire pipeline. It involves putting more thought into running your pipeline but often means the only tasks that get executed are copying a file and restarting your app
This is actually exactly what our platform helps with - instead of micromanaging this (and updating the configurations) you can rely on a friendly SaaS to do it for you.
I wouldn't call us "better" than Docker, we're more like "Take Docker and make it work better for CI/CD and staging servers"
Re:Launch HN: LayerCI (YC S20) - Staging servers that act li...
by CedarMills on Monday February 01, 2021 @11:25AM
(#25990037)
This comment reminds me of the comments people made about Dropbox originally: https://news.ycombinator.com/item?id=9224
Also, red flag: mis-use of the term DevOps for marketing purposes.
"There are a few ways of thinking about these files named ‘Layerfile’:"
It's not explained well what benefit there is to using VMs rather than containers. Later on it briefly mentions possibly better caching than Docker containers. If it's actually better than Docker, you are severely burying the lede. "Better than Docker" should be on the front page. It's also not explaining whether I need to throw away all the time and money I might have already invested in containers, or what this is and isn't compatible with.A lot of this solution is really built around optimizing one specific problem, which is caching during re-running whole CI pipelines. This limits the viability of your business. As soon as your customers figure out a new way to solve this problem, they don't need your custom platform anymore. I would consider LayerCI more of a specific feature of a much larger offering.
(In particular, the 'correc't way to solve this problem is to stand up an environment for your PR and structure your CI so you only re-run the parts that affect the particular change you want to make, rather than re-running the entire pipeline. It involves putting more thought into running your pipeline but often means the only tasks that get executed are copying a file and restarting your app)
P.S. You're installing the yarn GPG key and then not doing anything with it. Your node setup script isn't installing the yarn repo or yarn itself, so this is a throwaway command.