Коллеги, присоединяюсь ко всему, что сказано выше.
От себя добавлю.
unit-тесты на старый код — это бесполезное занятие, т.к. там наверняка быдло код, его качественными тестами покрыть будет крайне трудоемко. я бы сделал так.
1. на весь новые функционал писать unit-тесты. программистам дать для просвещения макконела и что-нибудь по практикам TDD, SOLID, GOF.
2. старый и новый функционал покрыть интеграционными тестами.
Если есть какие-то фоновые взаимодействия, выгрузки и прочее, это можно проверять.
Пользовательский интерфейс тоже можно тестировать автоматизированно.
см. BDD. Пусть в браузере прогоняется автоматически весь функционал сайта.
3. в качестве CI-сервера я использовал hudson. Меня вполне всё устроило.
тот же Jenkins — это его форк
4. за продакшен должен отвечать только один человек.
можно организовать это так. делаем отдельную ветку, или бранч, или вообще отдельный реп.
это как организуетесь.
в него может комитить только один человек. Этот человек делает ревью всего кода перед тем как залить его в продакшен репозиторий.
соответственно этот человек «выпивает мозги» программистам, чтобы всё так было. Ну а случись что, есть за это дело ответственный, с которого спрашивается в первую очередь.
5. на счет www-скрипта — это уж слишком, если б программистов было человек 30 и функционал выкатывался бы каждый день(или хотя бы раз в неделю разными людьми), то да, а так я думаю оно лишнее.
бывают ситуации, когда приходится делать отладку на боевом комитами и www-скриптом. Кто-нибудь из программистов обязательно так сделает…
