[MuffinFlavored]

I'm confused why I'd use this. My flow now is:

1. branch off of master

2. write a bunch of code that runs the risk of breaking stuff

3. deploy it to our already existing developer/staging environment

4. test it. if it is good, promote it to QA/UAT/CAT

does Dockup assume that companies don't already have the 3 main environments (dev/CAT/prod) set up?

Why would my service be worth anything in isolation? Usually when I deploy to staging, it is after I've already made e2e+unit+integration tests work locally, so I'm checking how live databases/load balancers/routers/etc. work in staging.

[emilsoman]

Step 3 in this flow is sometimes painful for big teams because developers have to wait in line if other developers are already using staging and may have to roll back databases after testing. Dockup gives the reviewer a chance to quickly test the feature without having to manually do deployments or start the app before merging the PR. Thanks for asking!

[MuffinFlavored]

I still don't perfectly grasp what this tool does.

How can you deploy multiple staging environments?

I guess I kind of get it now that I think through it.

Say you need 10 services for staging to work. They all talk to the staging database...

Does this DockUp thing also allow you to configure to deploy a database so developers aren't fighting over data/migrations in staging?

It sounds like a containerized development environment, but it's really only as good as the configuration job that is done for it.

How do I test new load balancer rules? Gotta have all of the load balancer images + configuration files in.

[lumengxi]

Yea, I agree. Step 3 is not a trivial setup for early-stage startups. Glad to see devtools companies trying to tackle this.

At the company I worked at, we built something similar using Heroku free dynos :) So that you can tag a PR and it automatically created a staging app using free Heroku dyno, it even came with a free database. The setup works but also quite spotty.

[zackkitzmiller]

This was a constant pain point for us as the engineering team grew. With a single staging environment, we could only have one changeset tested at a time. We built a tool like this internally and the engineers love it. When you have 20 feature going out in a week, it's not reasonable to have to wait for staging or qa to be available. We happened to call this 'review apps' but it's based on a similar principle. You can specify in the deployment tool which service you'd like to deploy as a review app, and a PR number.

This is incredibly useful with many interconnected codebases have related changes (I know, bad SoA. best practices are hard). Then I can point review-3918.SERVICENAME.service.XXX.stag's connection string to review-1111.SERVICENAME.service.XXX.stag to ensure that everything is working as expected.

[emilsoman]

We would love to interview you to understand your experience, can you please drop me a mail here: [e-mail]? Btw, we had the exact same requirement too - be able to test how a related change in multiple apps would affect the whole system. Check out our deployment form that helps us do this now: https://user-images.githubusercontent.com/1707078/53836663-6...