TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Launch HN: Dockup (YC W19) – On demand staging environments for dev teams

133 点作者 emilsoman大约 6 年前
We&#x27;re Emil and Yuva, co-founders of Dockup (<a href="https:&#x2F;&#x2F;getdockup.com" rel="nofollow">https:&#x2F;&#x2F;getdockup.com</a>). Dockup spins up on-demand environments so engineering teams can quickly test their code changes. When you open pull requests, Dockup creates disposable environments automatically and delivers URLs to your chatrooms; engineers don&#x27;t have to wait their turn to manually deploy to a staging server for testing their code changes. Anyone in the team can then click on these URLs and preview features before merging pull requests. Because each environment has all the services in the tech stack, it lets you catch bugs which usually happen only in production.<p>My co-founder and I were colleagues at our previous job (for ~6 years) where we worked as consultants, mostly working on Rails, React and Elixir projects and had the luck to work closely with many engineering teams. We often saw that teams would slowly lose confidence in their code as their codebases and team sizes grew and code changes would take longer to ship. At a payments company that we worked for, things often worked fine in dev but broke in production and eventually they started having company wide meetings before teams could deploy anything to production. Wanting to help developers ship faster and with more confidence, and also to scratch the itch of writing something in Elixir, we started building a tool as a hobby project, which eventually turned into our product.<p>Honestly, at first I thought that if we could build it, anyone else could build it internally too and no company would pay money for this, until we actually started talking to companies which have done it. We learned that it usually takes a few months for a developer to build an internal tool that automates PR review deployments. Most engineers told us they don&#x27;t like having to support this set up and keep it running after they&#x27;ve built it and moved on to solving other problems. We faced many problems on the way, for example - the need for pre-seeded prod like databases for testing features, being able to support architectural changes (for example, adding a message queue in the tech stack and testing it with Dockup) etc. We have now reached a place where we are able to onboard most of our customers without having to build custom features each time. We are excited to share what we have built with all of you! We are sure the HN community will have many knowledgeable engineers who have tried solving this problem and we&#x27;re looking forward to hearing your thoughts.<p>If you want to try Dockup now, you can do it by running the Dockup agent on your servers. If you don&#x27;t want to run your own servers, you can request access for the managed Dockup cluster by going to our pricing page and we&#x27;ll roll out access in a couple of days. Pricing starts at $75 for small teams.<p>Thank you for reading!

21 条评论

treis大约 6 年前
&gt; It spins up containers that simulate your tech stack, but it won&#x27;t be an exact replica of your production infrastructure. For example, if you use a managed postgres DB in AWS in your prod environment, in a Dockup environment, you would use a postgres Docker container that&#x27;s started using the official postgres image.<p>I don&#x27;t quite understand this. Why wouldn&#x27;t I want to spin up another postgres DB in AWS for testing?<p>I think that&#x27;s what I&#x27;m a bit stuck on. Being able to spin up a test environment on demand is cool. But if I&#x27;m going through the effort to do that, why not go through the effort to do the same for a production environment? Then I can use the exact production configuration to run my tests.
评论 #19315398 未加载
评论 #19315199 未加载
nagarjun大约 6 年前
As a manager of a remote team, I can see how this can be doubly useful to me! We already use Docker for development too but reviews still involve stopping what I&#x27;m doing to pull another developer&#x27;s code to test and merge. I couldn&#x27;t find any documentation for Dockup on your website. Is documentation available only if I&#x27;m signed in? I was just curious to see how it can be setup before signing up for an account.
评论 #19313402 未加载
评论 #19313780 未加载
kevan大约 6 年前
I like it. Back in 2015 I built something similar[1] for my company and it helped us make the transition from time-bound releases with QA on mainline to per-PR QA and CI&#x2F;CD.<p>[1] <a href="https:&#x2F;&#x2F;medium.com&#x2F;@kevanahlquist&#x2F;dockerui-at-bluestem-2890bf1bcd45" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@kevanahlquist&#x2F;dockerui-at-bluestem-2890b...</a>
评论 #19314772 未加载
benoror大约 6 年前
How is it different from Heroku Review apps? (<a href="https:&#x2F;&#x2F;devcenter.heroku.com&#x2F;articles&#x2F;github-integration-review-apps" rel="nofollow">https:&#x2F;&#x2F;devcenter.heroku.com&#x2F;articles&#x2F;github-integration-rev...</a>)
Operyl大约 6 年前
How do you feel you compare to the similar features in Gitlab’s product?
评论 #19314662 未加载
评论 #19313306 未加载
nloui大约 6 年前
This is great. Setting up proper staging environments has been on our procrastination list for a long time and as a small team, we haven&#x27;t invested engineering hours for a real setup yet. If this simplifies the process so much that we barely need to think about it, I totally get the value.
评论 #19314538 未加载
seantomburke大约 6 年前
I have been searching and waiting for someone to build this! Thank you so much! Currently reviewing code is a guessing game. &quot;Does it actually do what it&#x27;s supposed to do? I don&#x27;t know but the code looks sound.&quot; I have only the code to reference and maybe screen shots if they&#x27;re provided. I&#x27;m not going to spend the time to download the diff and deploy it myself just to see if the application is doing what it&#x27;s supposed to.
yingw787大约 6 年前
Interesting proposal! I have a number of questions:<p>- How much configuration is still required by the end user to leverage Dockup? How would it be different from a Vagrant&#x2F;Docker setup where you would define a Vagrantfile and Dockerfile?<p>- Why make pull request reviews with a development environment rather than a slimmed down production environment? Testing turnaround time?<p>- Do you guys anticipate on-premise deployments of Dockup?<p>Best of luck!
评论 #19313143 未加载
sz4kerto大约 6 年前
We have our own version of this -- we&#x27;re fully remote, so it&#x27;s an important thing to have. Basically we can deploy a full on-demand env with a single command. It&#x27;s very useful.<p>(Really, you just launched exactly the same features what we have already internally. :) )<p>Good luck.
评论 #19314483 未加载
firdaus大约 6 年前
I have this problem, we could have a lot of branches but only a certain number of environments e.g. dev, qa, stage etc.. So would this tool allow me to create environments dynamically so that I can test each branch standalone.
评论 #19321505 未加载
andrethegiant大约 6 年前
Why are you not listed on this page? <a href="https:&#x2F;&#x2F;www.ycombinator.com&#x2F;companies&#x2F;?batch=w2019" rel="nofollow">https:&#x2F;&#x2F;www.ycombinator.com&#x2F;companies&#x2F;?batch=w2019</a>
评论 #19313335 未加载
评论 #19313460 未加载
LeonM大约 6 年前
I always thought that the &#x27;W&#x27; in YC batch numbers stood for &#x27;winter&#x27;, or isn&#x27;t it? Or is &#x27;W19&#x27; in the title a typo and should it be &#x27;W18&#x27;?
评论 #19315089 未加载
评论 #19318016 未加载
wasd大约 6 年前
Suppose my application is dependent on the subdomain like &quot;customer1.wasdapp.com&quot;. Is your application able to spin up &quot;customer1.wasdstaging.com&quot;?
评论 #19314759 未加载
eddiezane大约 6 年前
Congrats on the launch! Any relation to Stream [0]? Your logo is very similar.<p>0: <a href="https:&#x2F;&#x2F;getstream.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;getstream.io&#x2F;</a>
评论 #19316070 未加载
评论 #19316058 未加载
评论 #19314207 未加载
OriPekelman大约 6 年前
As it is relevant .. plugging-in my own startup, platform.sh We do this with another twist ... our per-branch ephemeral staging clusters contain a full snapshot of production data. We believe strongly in immutability so what you are running in production is precisely what you tested in QA... And because production cloning relies on copy-on-write primitive it is basically immediate (think more in the dozens of seconds rather than multiple of minutes).
评论 #19315592 未加载
aboutruby大约 6 年前
How does it compare to Heroku review apps?
评论 #19314941 未加载
heroic大约 6 年前
How are you different from Jenkins X?
评论 #19313642 未加载
maddy82大约 6 年前
This seems like a great tool for companies that don&#x27;t have time to invest in dev ops.
mychael大约 6 年前
Might be useful for anyone who hasn&#x27;t heard of Docker yet.
arisAlexis大约 6 年前
no offense but not really world changing tech from YC batches
MuffinFlavored大约 6 年前
I&#x27;m confused why I&#x27;d use this. My flow now is:<p>1. branch off of master<p>2. write a bunch of code that runs the risk of breaking stuff<p>3. deploy it to our already existing developer&#x2F;staging environment<p>4. test it. if it is good, promote it to QA&#x2F;UAT&#x2F;CAT<p>does Dockup assume that companies don&#x27;t already have the 3 main environments (dev&#x2F;CAT&#x2F;prod) set up?<p>Why would my service be worth anything in isolation? Usually when I deploy to staging, it is after I&#x27;ve already made e2e+unit+integration tests work locally, so I&#x27;m checking how live databases&#x2F;load balancers&#x2F;routers&#x2F;etc. work in staging.
评论 #19313725 未加载
评论 #19314037 未加载