Речь все-таки идет про команду, работающую тесно над одним проектом. Если проект включает в себя 50-100 разработчиков, что-то мне подсказывает, что в рамках такого проекта будут группы разработчиков с на порядок меньшим количеством участников.
Не совсем это письма от роботов. Это письма от коллег, фактически отчеты о проделанной работе. На мой взгляд, это проблема позиционирования такой практики в головах.
По идее, собирать проект и хранить отчеты о неудачных сборках это обязанность системы сборки или непрерывной интеграции, а не хранилища. Пробовали ли вы внедрять в вашем проекте системы подобного рода?
Платформа проекта определяется заказчиком, платформа инфраструктурных инструментов выбирается разработчиками. Те скрипты на perl, про которые вы говорите, будут полезны другим разработчикам? Они облегчают работу над проектом?
Приведите, пожалуйста, пример файлов, которые участвуют в проекте, но у вас в хранилище не попадают.
Берусь утверждать, что класть сгенеренные артефакты в хранилище - зло, в подавляющем большинстве случаев. Это как с нормализацией баз данных: источник должен быть один, иначе неминуемы конфликты и несоответствия.
Для публикации собранных дистрибутивов можно использовать массу других, более привычных заказчику источников. Ftp-, http-сервер, samba share, и так далее.
Второй пункт работать будет, поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди этим будут пользоваться.
Текст был написан по итогам полуторачасового совещания по внедрению управления релизами в проекте, который существует уже три года. Поэтому я не стал бы называть все эти вещи очевидными для всех разработчиков.
В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: когда дизайн прекрасен. Я видел, как этот подход работает при плохом и при хорошем дизайнах, при начальных стадиях и на стадиях отладки. Лишь бы количество разработчиков было больше 1-2. Поэтому рискну сделать вывод, что некоторым просто лень писать тикеты и описывать поставленные задачи. Позиция понятная, но уважения не вызывающая.
Это значит лишь упрощенное вбивание настроек.
Я, кстати, качал версию EN-GB, поэтому у меня Thunderbird везде подставлял googlemail.com вместо привычного gmail.
Что ж, попробуем-с :)
Хороший вариант, спасибо.
Речь шла про идеологию, SCM в компании существует достаточно давно.
Речь все-таки идет про команду, работающую тесно над одним проектом. Если проект включает в себя 50-100 разработчиков, что-то мне подсказывает, что в рамках такого проекта будут группы разработчиков с на порядок меньшим количеством участников.
Берусь утверждать, что класть сгенеренные артефакты в хранилище - зло, в подавляющем большинстве случаев. Это как с нормализацией баз данных: источник должен быть один, иначе неминуемы конфликты и несоответствия.
Для публикации собранных дистрибутивов можно использовать массу других, более привычных заказчику источников. Ftp-, http-сервер, samba share, и так далее.
Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди этим будут пользоваться.
Текст был написан по итогам полуторачасового совещания по внедрению управления релизами в проекте, который существует уже три года. Поэтому я не стал бы называть все эти вещи очевидными для всех разработчиков.
В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: когда дизайн прекрасен. Я видел, как этот подход работает при плохом и при хорошем дизайнах, при начальных стадиях и на стадиях отладки. Лишь бы количество разработчиков было больше 1-2. Поэтому рискну сделать вывод, что некоторым просто лень писать тикеты и описывать поставленные задачи. Позиция понятная, но уважения не вызывающая.
Вот пример: http://operawiki.info/WebDevToolbar