Мысли, навеянные неделями разработок…

Знаете, у меня ситуация глупая, связанная с разработчиками. Есть проект, есть те, кто над ним работает… Парочка программистов, парочка кодеров (к примеру), кто рядом в LANе, кто удалённо, иногда меняются в расположении… Вроде у каждого своё рабочее место, но не у каждого есть то, что есть на сервере (4 версии MySQL, Apache, PHP, Ruby). SVN поставить может каждый из них, и пользоваться умею/научим, а вот поставить серверочек нужной конфигурации у себя на рабочем месте для разработки не самая лёгкая задача (не смотря даже не мои чёткие указания и пару попыток написать статьи об этом).

Способ правильный, но не используемый мною:
Можно сказать – крутитесь сами, как хотите, типо, это ваши проблемы. Но, кодер (а иногда и хитрожопый программер) прекрасно может доказать, что как-бы ему то этот сервер нахер не машине не сдался, и ресурсов много надо (для некторых это много), и ставить ему уметь его не надо, и у него и так хватает работы, тебе надо, ты и ставь. И вообще, зачем всё разносить по всем машинам, когда можно всё сделать на одной? Вобщем, слишком многие против…

Значить всё будет на одной машине. Сколько разработчиков – столько виртуальных серверов для одного проекта.

Способ почти правильный, но не используемый мною:
В каждом их рабочая копия, пускай отслеживают каждый сам, насколько у них свежие данные.
Чтож… Вроде всё хорошо и прекрасно… но, как только кто-то сделал коммит, значит всем, рано или поздно надо будет обновить свою версию на сервере. Делать экспорт и заливать заново, почти туда-же – дело на самое весёлое. У всех вечно нету времени и это должен делать тот, кто ближе к серверу, да так, что бы их правку вдруг не затереть – обидется, перезаливать не будут… Другая проблема – если он заболел, забыл прокоммитить, уехал кудато, не досягаем а изменения уже на сервере, но не в версии с SVN – отсечь их без кампликаций не легко, а на большом проекте, почти не возможно. Далее, как не странно, уже дважды были претензии, что проект с чекаутом из SVN занимает слишком много места (а оно раза в 2 больше) и сжирает много трафика (да, есть ребята с платным трафиком у нас). Вариант отлетает.

Способ не правильный, но используемый мною:
Чтож… сделаем чекаут проекта каждому в отдельный виртуальный сервер и дадим доступ. Вперёд, только работайте! Но тут получается, что я, в течении дня должен ходить и регулярно (не реже 3 раз) за всех обновлять их рабочую версия, делать коммиты и решать конфликты… Значит у меня, как разработчика-лидера пропадает уйма времени. Да, пересмотр чужого кода на конфликтах это хорошо, но не всегда это хочется делать… Плюс комментарии к коммиту не всегда попадают в самую точку, да и сам коммит не всегда в тему и к конкретному процессу/задаче. Зато все остальные довольны…

Хотя мне понятно, вроде-бы, почему они так любят брать файлы с сервера, править их у себя и загружать на сервер. Я бы сказал это “old school”. Тогда, в 1999-2002 (когда я начинал), для разработки мало кто афишировал, у нас, что у них там контроль версий и как этим пользоваться, а поставить CVS у меня тогда сил не хватило (а тем более разобраться как оно работает, всё пришло с годами). Я не знаю, с тех пор ли, но всё людям удобней работать именно так, на буквальном смысле напрямую, на боевом сервере сразу. И я отдаю себе отчёт в том, что при замечании: “эй, там вот надо на 10 пикселей левее, а вон там надо вывести ещё и такой-вот блок”, проще всё сделать сразу на боевом, а не делать чекаут, править, дебагить, делать коммит с комментарием, а потом только засылать на боевой сервер, да и ждать никому не хочется… А ещё, эта проблема обновлений рабочей версии, и решение конфликтов… оно пугает… конфликт, да вы что? а потом разбирайся с чужим кодом, как в него влезть и что он делает… а может я сделал тоже самое? Но надо как-то заставить всех переходить на правильное использование инструментов и нужными методами. Может даже у этой проблемы корни глубже… В обучении… А? Ведь везде сразу учат как использовать среду программирования, как работать одному, и никакого контроля версий, никакой групповой работы (не ну есть редкий случай проявлений данной науки, но очень редкий).

Вот такая вот проблемка у меня… Пока решаю её путём не самым приятным/правильным для меня… Но, вроде-бы, самым быстрым на данный момент… Хотя на грабли наступал, да… А кто знает какие похожие извращения, можете поделиться…

1 thought on “Мысли, навеянные неделями разработок…

  1. Самый правильный способ:
    1. Единый центральный сервер VSS/CVS/итд.
    2. Актуализировать локальную копию каждый должен сам. (но при необходимости несложно организовать автоматизированную почтовую рассылку о измененных модулях)
    3. Борьба с заливающими кривые либо непротестированные версии – в осном чисто административная. Ну или моральная, если разработчик вменяем. По выявлению невменяемых права на изменение особо важных модулей отбираются.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.