Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Проект автоматизированно собирается двумя командами. Первой (и единственной) командой он вынимается из репозитария, вторая команда — сборщик.
Запутался. Как понять эту фразу?
А разве "репозитарий", а не "репозиторий"? По-моему, второй вариант верный. Мы говорим "хранилище" :)
Правило 1 у нас на работе не соблюдается. Во-первых, в используемом нами ClearCase есть понятие private для файлов и каталогов, и это как раз не добавленные в систему контроля версий каталоги и файлы, которые нужны только конкретному разработчику, внутри хранилища они будут лишними. Во-вторых, архив с собранным дистрибутивом мы таки помещаем в хранилище, т.к. его оттуда берут тестеры и заказчики ("потребители"). Они не собираются "потребителями", они могут быть пересобраны нами, при обнаружении ошибок сборки, и взять "потребителями" повторно из того же места. А история сборки позволяет отследить ошибки при сборках.
Правило 1 у нас на работе не соблюдается. Во-первых, в используемом нами ClearCase есть понятие private для файлов и каталогов, и это как раз не добавленные в систему контроля версий каталоги и файлы, которые нужны только конкретному разработчику, внутри хранилища они будут лишними. Во-вторых, архив с собранным дистрибутивом мы таки помещаем в хранилище, т.к. его оттуда берут тестеры и заказчики ("потребители"). Они не собираются "потребителями", они могут быть пересобраны нами, при обнаружении ошибок сборки, и взять "потребителями" повторно из того же места. А история сборки позволяет отследить ошибки при сборках.
"взяты потребителями" я имел в виду
Приведите, пожалуйста, пример файлов, которые участвуют в проекте, но у вас в хранилище не попадают.
Берусь утверждать, что класть сгенеренные артефакты в хранилище - зло, в подавляющем большинстве случаев. Это как с нормализацией баз данных: источник должен быть один, иначе неминуемы конфликты и несоответствия.
Для публикации собранных дистрибутивов можно использовать массу других, более привычных заказчику источников. Ftp-, http-сервер, samba share, и так далее.
Берусь утверждать, что класть сгенеренные артефакты в хранилище - зло, в подавляющем большинстве случаев. Это как с нормализацией баз данных: источник должен быть один, иначе неминуемы конфликты и несоответствия.
Для публикации собранных дистрибутивов можно использовать массу других, более привычных заказчику источников. Ftp-, http-сервер, samba share, и так далее.
Пример файлов: у нас в команде Perl не используется, и если я положу свои скрипты на Perl для работы с исходниками (форматирование под принятые у нас требования, генерация служебных комментариев, генерация XML на основе списка шаблонов) меня все будут долго спрашивать: что это такое, а потом придет начальство и спросит: а почему Perl, родной? Однако т.к. эти скрипты зачастую завязаны на структуру каталогов внутри хранилища, они лежат там, рядом, в private виде. Обобщая можно сказать, что это такой островок свободы, когда у тебя есть возможность иметь свои средства для выполнения задач. Бывают кстати случаи, когда спрашивают: как ты это делаешь и просят нажать "Add to source control", чтобы тоже это использовать.
Про публикацию: да, публикация может производиться на FTP. А можно закатывать проект на болванку и отвозить клиенту на тройке с бубенцами, сути дела это не меняет: сборка у нас рассматривается как часть разработки, у нее есть свой описанный процесс, за нее отвечает несколько человек, и она может содержать свои ошибки. И эти ошибки (в т.ч. и их виновников) можно отследить только через хранилище. И рано или поздно может возникнуть ситуация, когда сборка явно не удалась, и поводом для отправки новой тройки с бубенцами будет именно Check in релиза с соответствующим комментарием.
P.S. я, как обычно, не претендую на истину, просто делюсь опытом.
Про публикацию: да, публикация может производиться на FTP. А можно закатывать проект на болванку и отвозить клиенту на тройке с бубенцами, сути дела это не меняет: сборка у нас рассматривается как часть разработки, у нее есть свой описанный процесс, за нее отвечает несколько человек, и она может содержать свои ошибки. И эти ошибки (в т.ч. и их виновников) можно отследить только через хранилище. И рано или поздно может возникнуть ситуация, когда сборка явно не удалась, и поводом для отправки новой тройки с бубенцами будет именно Check in релиза с соответствующим комментарием.
P.S. я, как обычно, не претендую на истину, просто делюсь опытом.
Платформа проекта определяется заказчиком, платформа инфраструктурных инструментов выбирается разработчиками. Те скрипты на perl, про которые вы говорите, будут полезны другим разработчикам? Они облегчают работу над проектом?
По идее, собирать проект и хранить отчеты о неудачных сборках — это обязанность системы сборки или непрерывной интеграции, а не хранилища. Пробовали ли вы внедрять в вашем проекте системы подобного рода?
Достаточно неплохо данная тематика описана в книжке Фредерика Брукса "Мифический человеко-месяц".
второй пункт работать не будет... если при любом изменении в коде или документации, будет приходить письмо, то в конечном итоге, все на эти письма забьют и они будут копиться в какой нибудь папочке в оутлуке... кроме того, не каждому разработчику интересно знать что происходит в других модулях, к которым он не имеет никакого отношения...
гораздо эффективнее, по крайней мере для документации, выпускать release notes, с определенным периодом, скажем каждую неделю или две, в зависимости от количества изменений...
для кода, просто, нужно вести history для каждого файла, к которой, можно обратиться в любой момент... любая SCM система это поддерживает...
пункт 4... я бы не хотел работать с компанией, у которой нет багтрекера
пункт 5 не всегда работает, особенно на ранних стадиях проекта, особенно при отсутствии хорошего дизайна.
вообще в статье, как мне показалось, автор хотел добиться определенного уровня абстракции, описывая очевидные вещи, но это не удалось, и осталась привязка к каким-то определенным "проектам", которые не применимы для всех компаний...
гораздо эффективнее, по крайней мере для документации, выпускать release notes, с определенным периодом, скажем каждую неделю или две, в зависимости от количества изменений...
для кода, просто, нужно вести history для каждого файла, к которой, можно обратиться в любой момент... любая SCM система это поддерживает...
пункт 4... я бы не хотел работать с компанией, у которой нет багтрекера
пункт 5 не всегда работает, особенно на ранних стадиях проекта, особенно при отсутствии хорошего дизайна.
вообще в статье, как мне показалось, автор хотел добиться определенного уровня абстракции, описывая очевидные вещи, но это не удалось, и осталась привязка к каким-то определенным "проектам", которые не применимы для всех компаний...
Второй пункт работать будет, поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди этим будут пользоваться.
Текст был написан по итогам полуторачасового совещания по внедрению управления релизами в проекте, который существует уже три года. Поэтому я не стал бы называть все эти вещи очевидными для всех разработчиков.
В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: когда дизайн прекрасен. Я видел, как этот подход работает при плохом и при хорошем дизайнах, при начальных стадиях и на стадиях отладки. Лишь бы количество разработчиков было больше 1-2. Поэтому рискну сделать вывод, что некоторым просто лень писать тикеты и описывать поставленные задачи. Позиция понятная, но уважения не вызывающая.
Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди этим будут пользоваться.
Текст был написан по итогам полуторачасового совещания по внедрению управления релизами в проекте, который существует уже три года. Поэтому я не стал бы называть все эти вещи очевидными для всех разработчиков.
В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: когда дизайн прекрасен. Я видел, как этот подход работает при плохом и при хорошем дизайнах, при начальных стадиях и на стадиях отладки. Лишь бы количество разработчиков было больше 1-2. Поэтому рискну сделать вывод, что некоторым просто лень писать тикеты и описывать поставленные задачи. Позиция понятная, но уважения не вызывающая.
Второй пункт работать будет, поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
Я имел неосторожность года 4 назад проверить на команде из 5 человек. Через неделю у 3 из них стоял фильтр, автоматически убивающий извещения о коммитах.
Более того, я очень часто встречаю следующую позицию: "письма от роботов читать незачем, в них все равно нет ничего интересного". Если писем от роботов мало (до 20-30 в день) с этим еще удается бороться. Если больше — сизифов труд. Общение с tash can.
Думаю rss лента в этом плане лучше. У меня к примеру прикручена rss лента к изменениям в репозитарии. Очень даже неплохо работает.
Идея разумна — прежде всего в том отношении, что вносит элемент добровольности. Одно дело — навязать информацию (что мы имеем в случае с рассылкой), совсем другое — постепенно убеждать в ее активности.
BTW, однажды высказывалось довольно разумное, в основе своей, предложение: автоматически постить в блог проекта запись о коммите от имени автора этого коммита. Это создает среду для обсуждения конкретного блока изменений. Останавливает то, что это тоже может стать навязыванием информации.
BTW, однажды высказывалось довольно разумное, в основе своей, предложение: автоматически постить в блог проекта запись о коммите от имени автора этого коммита. Это создает среду для обсуждения конкретного блока изменений. Останавливает то, что это тоже может стать навязыванием информации.
Идея разумна — прежде всего в том отношении, что вносит элемент добровольности. Одно дело — навязать информацию (что мы имеем в случае с рассылкой), совсем другое — постепенно убеждать в ее активности.
К тому же это позволяет просматривать старые коммиты :) Еще одной альтернативой являются архивы почтовых рассылок доступные через IMAP протокол. Хотя они и проигрывают в чем-то удобству работы с rss лентой.
BTW, однажды высказывалось довольно разумное, в основе своей, предложение: автоматически постить в блог проекта запись
о коммите от имени автора этого коммита. Это создает среду для обсуждения конкретного блока изменений. Останавливает то, что это тоже может стать навязыванием информации.
Да хорошая мысль к тому же можно автоматически генерить как ленты собственно постов, так и ленты коментариев.
ЖЖ, кстати, так разрабатывается: http://community.livejournal.com/changel…
Хороший вариант, спасибо.
Хороший вариант, спасибо.
однако важно, чтобы для разработчиков блог как формат/как инструмент был привычен, понятен. это не всегда так, к сожалению.
Увы, такая проблема есть. Правда, бОльшие проблемы я огреб при попытке внедрения wiki. :(
а у вас есть опыт внедрения и того, и другого?
внедрение wiki в результате считаете удачным? какие проблемы вам встретились, что так и не удалось решить?
внедрение wiki в результате считаете удачным? какие проблемы вам встретились, что так и не удалось решить?
Есть опыт внедрения и того, и другого. Я склонен рассматривать его (их) как неудачный.
Основные проблемы (кратко):
1. Программеры привыкли, что доки и прочии тексты нужно писать из под палки.
2. Распространенность практики заметания мусора под ковер.
3. Несовместимость форматов: трудно вытащить из вики текст в требуемые проектные документы.
Будем учиться на ошибках.
Основные проблемы (кратко):
1. Программеры привыкли, что доки и прочии тексты нужно писать из под палки.
2. Распространенность практики заметания мусора под ковер.
3. Несовместимость форматов: трудно вытащить из вики текст в требуемые проектные документы.
Будем учиться на ошибках.
а из вики точно не существует конверторов во что-то более удобоворимое?
Чтобы на выходе из N страниц получался вордовый документ со стилями — такого даже близко не нашел.
Самому делать — геморройно.
Самому делать — геморройно.
а в DocBook конвертора из вики не существует?
Отвечу честно: не искал :)
жаль :(
я натыкался на такую штуку - wt2db, но пока не рисковал перевести проекты на вики - для начала хотелось бы получить отзывы тех, кто пользовался.
я натыкался на такую штуку - wt2db, но пока не рисковал перевести проекты на вики - для начала хотелось бы получить отзывы тех, кто пользовался.
1. Программеры привыкли, что доки и прочии тексты нужно писать из под палки.
Doxygen?
2. Распространенность практики заметания мусора под ковер.
Дада есть такое.
3. Несовместимость форматов: трудно вытащить из вики текст в требуемые проектные документы.
Doxygen? А проектные документы в PDF не принимают ?
А чем поможет Doxygen?
P.S. Служба QA принимает только в DOC. :)
P.S. Служба QA принимает только в DOC. :)
я бы вообще расстреливал заказчиков (будь то внешние или внутренние), которые требуют документацию в doc :) разработчику с doc работать - ну совсем не удобно. а создавать что-то бессмысленное - я не понимаю зачем? чтоб только было?
Doxygen это система автоматической генерации документации по коментариям в исходном коде аля javadoc. Такую систему документации разработчики по заверениям Брукса программисты используют более охотно. На выходе все что угодно, используется DocBook.
Если они их только читают, то давать им в PDF. И произвести разъяснительную работу о пользе PDF.
Служба QA принимает только в DOC. :)
Если они их только читают, то давать им в PDF. И произвести разъяснительную работу о пользе PDF.
Вероятно, я неверно сформулировал вопрос. Что такое Doxygen — я знаю хорошо. Мне непонятно, чем он поможет в моем горе. :)
Ну я идея порулить службой QA — интересна, но потребуется лет 3-5, чтобы подняться в административной иерархии на должный уровень. Я не готов к такому подвигу. :)
Ну я идея порулить службой QA — интересна, но потребуется лет 3-5, чтобы подняться в административной иерархии на должный уровень. Я не готов к такому подвигу. :)
Doxygen позволит склонять программистов к написанию документации. Если используется среда разработки которая позволяет его туда интегрировать, то еще лучше. Хотя конечно вопрос еще состоит подойдет ли такая документация QA.
Ну а насчет QA могу только сказать: - О ODF когда ты как стандарт снизойдешь на QA!
Ну а насчет QA могу только сказать: - О ODF когда ты как стандарт снизойдешь на QA!
Службу QA - по ушам (я сам QA). Пусть PDF читают. Заодно гарантия, что ничего важного "подтерто" не будет :)
Не совсем это письма от роботов. Это письма от коллег, фактически отчеты о проделанной работе. На мой взгляд, это проблема позиционирования такой практики в головах.
>поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
а если команда из 50 или 100 человек?
>Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди >этим будут пользоваться.
смотреть на историю изменений и понимать, что произошло с файлом за определенный промежуток времени.
>по итогам полуторачасового совещания по внедрению управления релизами
ИМХО, за полтора часа, нельзя наладить работу SCM, в компании, в которой этого никогда не было...
>В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: >когда дизайн прекрасен.
Этот должно работать, я не спорю с этим. Но в определенных ситуациях, на начальных стадиях проекта, это может казаться не естественным...
>что некоторым просто лень писать тикеты и описывать поставленные задачи.
Это должны делать те, кто ставит задачи.
а если команда из 50 или 100 человек?
>Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди >этим будут пользоваться.
смотреть на историю изменений и понимать, что произошло с файлом за определенный промежуток времени.
>по итогам полуторачасового совещания по внедрению управления релизами
ИМХО, за полтора часа, нельзя наладить работу SCM, в компании, в которой этого никогда не было...
>В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: >когда дизайн прекрасен.
Этот должно работать, я не спорю с этим. Но в определенных ситуациях, на начальных стадиях проекта, это может казаться не естественным...
>что некоторым просто лень писать тикеты и описывать поставленные задачи.
Это должны делать те, кто ставит задачи.
Про команду из 7 человек.
Речь все-таки идет про команду, работающую тесно над одним проектом. Если проект включает в себя 50-100 разработчиков, что-то мне подсказывает, что в рамках такого проекта будут группы разработчиков с на порядок меньшим количеством участников.
Речь все-таки идет про команду, работающую тесно над одним проектом. Если проект включает в себя 50-100 разработчиков, что-то мне подсказывает, что в рамках такого проекта будут группы разработчиков с на порядок меньшим количеством участников.
Про SCM.
Речь шла про идеологию, SCM в компании существует достаточно давно.
Речь шла про идеологию, SCM в компании существует достаточно давно.
Вот логи, например, в репозитарий класть не надо — вам не потребуется управление версиями логов. Как не надо класть и упакованный (скомпилированный) код вашего проекта или документацию, собранную по исходому коду. Потому что логи и пакеты собираются автоматически и в любой момент можно эту процедуру повторить.
Я неоднократно убеждался, что это неверно. Если артефакт X можно воспроизвести из других уже размещенных в репозитории артефактов, но это требует значительных затрат времени или других ресурсов, то его имеет смысл также положить в репозиторий.
Примеры:
1. Лог нагрузочного тестирования. Да, мы можем его воспроизвести. Но для этого нужно снова получить железо, которые временно выделялось для теста, и еще раз выполнить нужные прогоны. Итого, к примеру, 18 часов. Один (в лучшем случае) убитый рабочий день. Во вполне реальном случае, когда для тестирования арендовались ресурсы в Data Fort'е, это вместе с выбиванием денег на повторное тестирование заняло бы с неделю. И вызвало бы у руководства резонные сомнения в моей вменяемости.
Кроме того, я не вижу ничего странного в том, чтобы, к примеру, сравнить между собой две версии логов от разных прогонов — для упомянутых результатов нагрузочного тестирования я это делал.
Понятно, это не означает, что каждый лог уровня debug, записанный программой, нужно класть в репозиторий. :)
2. Бинарники отдельных компонент проекта. Разработчик получает задание исправить дефект в компоненте A. Он просто поднимает из репозитория исходники этого компонента и бинарники для компонент B, C ... Y, Z, которые нужны для сборки и тестирования. Это занимает 1-2 минуты. Вместо того, чтобы вынуть из репозитория все исходники (15 минут) и провести полную сборку (еще 10 минут).
3. Результаты работы коммерческого софта, на который имеется ограниченное количество лицензий.
Каждому изменению в репозитарии соответствовует тикет ... Не стоит вносить в репозитарий сразу несколько изменений и решать тем самым несколько тикетов, это усложнит исследование и анализ проведенных изменений.
С одной стороны — истинная правда. С другой стороны — я пока не видел проектов, где это удавалось бы выдержать. Причины банальны:
1. Отсутствие необходимой поддержки со стороны среды разработки. Если учесть, что лень — одна из главных добродетелей программиста, то заставлять его вручную переписывать номер тикета из ClearQuest'а в окно ввода комментария Subversion'а можно только очень недолгое время. Стоит отвернуться — и все на это забивают. Варианты применения мер типа "лишение квартальное премии за повторное нарушения формата комментария" — не рассматриваю. Я так через два месяца останусь в проекте наедине с PM'ом.
2. Зачастую несколько тикетов закрываются одной группой связных правок. Случай, когда несколько тикетов отражают проявления одной и той же ошибки в коде — очевиден. Рассмотрим и чуть более сложный случай: для закрытия тикетов X, Y и Z я сделал утилитный класс Foobar и поюзал в классах A (для тикета X), B (для тикета Y) и C (для тикета Z). Под каким тикетом мы будем коммитить Foobar и как это потом нам поможет при разборе полетов?
И, кстати, я совершенно не уверен, что есть реальная необходимость в отслеживании таких связей — мне обычно хватает макроуровня, на котором к номеру версии привязан список всех тикетов. Разбор на микроуровне я за прошедший год проводил ровно 1 (один) раз. Действительно, мне бы очень помогли комментарии к коммитам с указанием номера тикета. Я бы потратил не 2 часа, а 10 минут. Но подозреваю, что все остальные разработчики для того, чтобы обеспечить меня этими комментариями, затратили бы на 2 порядка больше времени.
Исталляция боевого кода вообще должна уметь обновляться, а также откатываться к предыдущей версии без каких-либо потерь данных.
Согласно лично моему опыту, не "должна", а "как хорошо, если это удается сделать". Простейший пример: зачастую новая версия имеет новую структуру БД, которая просто содержит больше полей. При downgrade мы либо теряем информацию из этих полей, либо городим дополнительные таблицы и триггеры, чтобы хоть как-то временно сохранить эту информацию и поддержать ее целостность. После 3-4 таких итераций ДБ дизайнер и админ сделают сеппуку на пороге кабинете менеджера проекта.
Хороший коммент, спасибо, но отвечать на него сейчас и обсуждать будет очень тяжело: очень уж большой.
Что ж, попробуем-с :)
Что ж, попробуем-с :)
По поводу "каждому изменению в репозитарии соответствует свой тикет" - у нас вполне выдерживается такая методика.
1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.
Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.
А вот рассылка всем содержимого commit-ов - это в самом деле спам, не могу представить зачем оно может быть нужно в таком виде.
1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.
Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.
А вот рассылка всем содержимого commit-ов - это в самом деле спам, не могу представить зачем оно может быть нужно в таком виде.
Я бы добавил пункт - автоматическое тестирование. Похоже мы наконец-то дошли до стадии когда тесты становятся необходимой частью процесса разработки.
Планирование составов релизов и управление релизами/итерациями по методологиям семейства Agile отлично реализовано в Системе управления процессом разработки - http://www.devprom.net
- Автоматическая (или одной кнопкой) выгрузка справочников из баз данных, в виде тех же sql insert скриптов. Разработчики изменения вносят непосредственно в базу данных, а перелить в VCS забывают. Пару раз теряли help. Если этого нет в CVS - это не существует.
- Автоматическое формирование скриптов создания объектов базы данных, типа create table. По той же причине.
- Единая информация по настройкам deploy-серваков. Суть: несколько разработчиков, один проект, каждый поставил себе на deploy-сервере по Tomcat-у (это Java web server) или, что тоже самое, поставил у себя на локальной машине. Работа приложения зависит от настроек сервера (datasources например). Кто-то из разработчиков добавляет в приложение и своего Tomcat-а какой-нибудь параметр и при следующем VCS update твое приложение перестает работать, его же приложение работает как надо. А тебе приходится сверять настройки серверов.
- Версионность. В любой момент времени быстро определить, какой релиз стоит на тестовом серваке, какой на разработческом, какой в продакшене. Чтобы не приходилось, прийдя из отпуска, бегать и узнавать, какой же все таки релиз стоит в продакшене или на тестировании. Номер релиза должен быть доступен или в меню "О программе" или в заголовке web-страницы, в общем должен легко и быстро определяться.
- Номера релизов, номера версии. Хорошо бы иметь четко прописанные правила, как назначаются номера релизам. Раньше я об этом не думал, но проект рос, фиксились баги, плодились версии и пришлось выработать правила. Эти правила есть у Linux (major/minor, чет/нечет), есть у Cisco, есть у Microsoft, у всех по-разному. Нашу схему я описывать не буду, каждый может по своему опыту привести пример, главное что эти правила есть и хоть как-то описаны.
- Место, где описаны все сервера, на которых размещается приложение: с их URL, путями на сервере, портами, логинами / паролями (разработческие или тестовые серваки), например в той же wiki. У нас например на одном физическом сервере развернуто несколько Tomcat-ов: несколько разработческих, один под сервер отчетов, один для тестера и один для тех. писателя. И если какой-нибудь из последних падает, надо зная всего лишь URL добраться до логов и узнать причину. Также сильно это помогает, когда у вас приложение состоит из FrontEnd и BackEnd частей и надо быстро по FrontEnd URL добраться до BackEnd server logs.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 правил гигиены при управлении релизами проекта