Is such web development setup/practice suitable at workplace?_问答_开发者

I'm working at web development company(for half a year now), it is my first workplace. But one thing we do there bugs me quite a bit. So I wanted to get input from more experienced people. I'm not sure if this is best place to ask, but i hope answers to this question might be useful and interesting for others too.

My main and most likely only dissatisfaction with job comes from the fact that we commit to live system(we have a web portal that runs on php and mysql), that is I commit code and changes are instantly visible on-line. It is no big deal for small or quickly detectable errors. But its a big problem when some hideous error creeps in, i.e. links are generated wrongly in some place and you can 开发者_StackOverflow社区reach some page with two different url(hits pages rank...), it is easy to miss such stuff for some days. (Or is it? Maybe I'm just not careful enough?) But I really try to check everything before committing and we also use phpunit and selenium(test are written by same person who writes code, after writing code) for testing(though test coverage could be grater).

So my question is: Is it common to do commits directly to on-line system when doing web development?

It's sadly common practice for a lot of new media agencies and startups (I have often seen that and it makes my eyes burn) but it's not at all best practice.

Good practice would be, having a development server, a staging site and a productive/live site.

Definitely not!

The most common scenario is to have at least 3/4 environments:

Development environment: Each developer commits his own modifications and runs his tests on his personal environment.
Integration environment: Every components of the application are merged together allowing everyone to see if everything is ok. Be carreful of Big-Bang integration though.
Beta-Test environment: When everything has been fixed and checked during the integration phase, you move to the beta-test phase. If there isn't a specific team for that, it is often done by the developers (each developer tests the functionnalities made by others in order to avoid obvious subjective issues).
Production environment: What the customer uses.

This is what I learnt from my very short experience (5 months internship), hope it helps!

This is not a very good practice at all. What has been done in most of my jobs is there is a test site that is a copy of live and code is comitted there first and tested there. If there is no problems on the test site, then the code can be pushed t the live site. Committing straight to the live site can cause errors that could have been caught by committing to a test site.

This is not a good idea for most customer facing web applications. If the site is barely used or is internal only though it is a common practice to commit/publish directly to the production environment if the company does not want to allocate testing resources to something with low visability.

This seems a bad practice from the first glance.

But consider the following. If a company is small and does not have a testing team or at least many enough developers, which could be assigned to additional testing of code commited by other developers, having a testing sandbox would result in developer testing code on his machine, then commiting, do SAME testing in the sandbox (if testing is manual, it will be less thorough for sure the second time, imagine doing same manual testing task two times in a row), then moving changes to the production environment. What are chances of finding a bug in the sandbox, if that developer did not find it on this local machine?

Also there always will be differences between the sandbox and the production environment. So if code works in the sandbox, it does not guarantee, that it will work in production.

Finally consider cost of maintaining the testing environment. Fast-growing projects with small teams simply cannot have that.

So if the team is very small - commiting to production with A LOT of local testing is the preferred way. Otherwise copying code from one place to another and do same testing by the same person will be too frustrating, time-consuming and useless.

If there are testing resources - you should consider having an additional testing environment, of course.