Internal/External Development Server Setup

Question

I'm trying to avoid the problem of making an assumption and asking the wrong question. I'm going to describe the situation I'm in and what the problem is.

I presently have a development server which runs development and testing databases. The developers run apache locally but connect to the test server databases so that everyone is on the same page. As time has gone by, the responsibilities of this server have grown. It is often used as a staging area for clients to sign off on changes. Meanwhile, the number of clients and databases has grown. Today, the development server ground to a halt. This was a real disruption to today's workflow for the development team.

A mixture of active development and CRON tasks that were set up during testing eventually slowed the server to the point that it was unusable. I believe that the server's disk access was the bottleneck.

I've asked for hardware upgrades previously, sadly they have not been forthcoming from management. A hardware upgrade would only do so much, also. I'm wondering if there's a better way to achieve what we're wanting, and want to set up the new server the right way when it arrives.

Ideally I'd like a system that it's easy to "stop" sites, including their cron ad making their staging URLs inaccessible, when they're not in active development. Equally important is that I'd need a simple way to "start" them again, preferably via a UI so our non-technical staff can do it.

I like the idea of a docker/vm-based solution but I'm not 100% sure how I'd maintain this. The biggest hurdle to using something like this is probably that I'm not sure how I'd be able to set these up for use as a staging environment.

Answer 1

You could assign each test project its own high port to use instead of the normal SQL port, and forward those ports to the real SQL server on 1433 (or wherever it is). Then you could just control the port forwarding. You could do the same with HTTP ports.

They could either be forwarded on the server itself (with iptables or firewalld), or on the clients (with firewalls, ssh tunneling, or whatever they can use on their platforms).

If it was done on the client side, you wouldn't have to give all of your developers root access on the server to turn their ports back on. Another benefit would be that if the server became totally unusable due to too much load, you could still turn off port forwarding on clients until the load became more manageable and you could access the server again.

Answer 2

Isolating development from user acceptance testing would be useful. A couple ways to do that.

Split the resources into separate dev and uat VMs. Moving from dev to uat is only done when another developer signs off that it doesn't kill performance or be otherwise terrible.

Have developers run their own changes on their own workstations. Have deployment tools that can spin up VMs with a local copy of the staging database and their code revision. After that branch is merged, proceed with integrated testing on the staging/uat system.