If you’re in webdev and stuck with a single staging or testing server, my heart goes out to you. That probably means you and your team work real hard on designing and developing amazing things, and then at the end of the sprint when it’s all supposed to come together in a glorious, jaw-dropping demo, something goes 💥.

😭

Developers are confused, Project Managers are embarrassed, and Stakeholders are frustrated. Morale tanks like a swiss cheese submarine 🧀. The team is stuck with a few bad options: ship the broken thing and hope to have time to fix it later, scrub the launch and do it right, or pull an all-nighter to hotfix the release.

I don’t know about you, but I don’t like any of those options.

What caused the “boom”? Often the team will find it was something small, like a missing semicolon, or maybe as embarrassing as [cough, cough] misunderstanding entirely how a new feature was supposed to work.

But those things are actually symptoms of a deeper issue. Underneath the huge gaping crater of that failed demo is a pernicious anti-pattern in the entire agile webdev process: a single staging / testing server.

The bottleneck of a single staging server

Given the rise of tools like Docker and Kubernetes, the amount of time, money, and hair lost to the bottleneck of limited staging servers is truly a tragedy. Friends, how are we still in this place?! We don’t need to be stuck with just one or two servers to test on.

We talk all day about “Agile”, “Scrum”, or “Kanban”, but our process doesn’t actually work that way. We can’t see what is being worked on in an “agile” manner, and then guess what happens: 💩 meet fan.

To me, this bottleneck is the most frustrating anti-pattern of our day. The technology is there. And, there are tools that make use of it. (If you’re in the market, Tugboat is obviously the best option. 💅 )

Remove the bottleneck: ship every commit.

No matter where you host or what your budget is, there’s a solution to this problem. Stop being reactive and start being proactive with your QA and demos. Get some tooling in place to give you automated, fully working website previews for every pull request.

Test everything all the time, and demo anything any time. And if you're not sure how, reach out, I'm glad to help.