I will second and third many of the above responses: Having each developer with an Apache instance on their workstation is not a bad thing at all.

When major code changes need to be made that will result in things being broken for a substantial period of time, it saves everyone a good deal of heartache.

In fact, I consider it one of the major advantages of using open source. If you were developing in Cold Fusion, you'd have to spend thousands of dollars a seat to give everyone a development environment they can wreak utter havoc on without fear.

In order to develop successfully with more than a few developers, however, you have to be able to transition code from workstation to production in such a way as to ensure that any one developers' tweaks do not break anything as they move from their customized workstation to a generic production environment.

That would entail:

• Good code revisioning; e.g., with CVS
• A multi-stage release process in which
  1. Developers commit working code to CVS
  2. The (working) code changes are checked out to a collective development environment which is maintained to be like the production environment, but which developers can feel free to make changes to (e.g., to the back end)
  3. Once the code passes muster on the development server, it is migrated by someone in charge of the release process to a QA server and a walk-through is done of the release process. The QA server should be kept as close to production as possible, mirroring the back end if you've got one. After the walk-through is successfully completed, the code changes are tested on the QA server. If either the walk-through or QA process is unsuccessful, the QA server is restored to its original state and you wash-rinse-repeat until everything goes smoothly.
  4. Only after the walk-through and QA are successful on the QA server is the code pushed to the production environment.
• A rigorous release process in which only one or two people have access to the QA and production environments. All code changes must go through that person or persons before being considered for release.

As a side benefit, your developers become much more familiar with the environment that their code runs in. They are better off because they have improved professionally, and you are better off because now you have a whole team that can help you diagnose critical production problems rather than just a handful of people.

Hope this helps :-)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.