Common Server Setup / Workflow [closed]

Question

Basically I'm wondering what the most common server setup up is for a web company. At the company i work out now we have 1 server with all our clients sites on. We sometimes work locally and upload, but 9 time out of 10 end up developing on the live server itself. Now this isn't ideal and it causes all sorts of problems, not to mention making problem finding difficult (due to logs being clogged with debug errors etc.).

i have been hearing alot about people having production servers, staging servers and development servers and im thinking that would be the way to go.

The setup I'm thinking is:

Production Server - Only live sites go on this. Nobody has FTP access except server admin. phpSuExec is installed so each site runs as its own user. Server is highly optimised. All uneccesary ports disabled etc.

Staging Server - clone of production server, without phpSuExec, but still restricted access.

Development Server - Internal server that all employees use. No FTP restrictions, can install productivity aiding software like SASS, xdebug and have less restrictive security rules etc.

The work flow would then be: everybody works on the development server. When the site needs to be viewed by the client, or tested in a production environment it is moved to the staging server. If there are issues, back to the development server, fix issues and push back to the staging server. Then once all issues are fixed and the client is happy we move the site to the production server.

I would be interested in any advice / pitfalls of the above system, and how other companies do this.

All servers are LAMP, running Ubuntu

Answer 1

The 3-tier setup is very common, for obvious reasons.

I recommend some changes to what you already listed, though:

• Your staging server should be an exact copy of the production environment.
  This has the huge advantage that staging -> production deployments are as smooth and error-free as humanly possible, and since such deployments may involve downtime, you want this.

• That said, actual access to the staging environment can be less restricted than it is on production, simply so DEV and QA/UA can also get access for troubleshooting purposes.
  You may want to restrict this to read-only access to check configuration and read log files, but it may save time in the long run; this typically depends on your usage patterns of these environments.
  If the shop is big enough that you have separate DEV and QA departments, then by all means keep the staging environment completely separate from DEV as well; large shops usually have a completely separate release team that is responsible for exactly this stage of deployment.

Answer 2

I agree with @adaptr and would add that developers should each use their own environment for development and check changes into source code control. This prevents them from stepping on each others changes and prevents one developer from breaking the server and putting everyone out of work for a day. The "development server" should be published to automatically from those checkins and will serve as an integration environment for all the changes.