Не знаю в какой форум кинуть, решил сюда.
Начальство требует изготовить по неск. проектам документ под названием "Политика релизов".
Среди прочих там дб пункты
— подход к компоновке релиза
— подход к сборке релиза
— подход к тестированию релиза
Что это такое -- само начальство не знает, но простые очевидные ответы (типа сборка автоматизированная, тестирование функциональное и т.п.) ему не нравятся
Поэтому, если не в лом, поделитесь плз мыслями начет того что еще может иметься в виду (или мб ссылочку на какую-нить методику по этому поводу)
Tyo>Не знаю в какой форум кинуть, решил сюда. Tyo>Начальство требует изготовить по неск. проектам документ под названием "Политика релизов". Tyo>Среди прочих там дб пункты Tyo>- подход к компоновке релиза Tyo>- подход к сборке релиза Tyo>- подход к тестированию релиза
Для начало не плохо бы определится что такое релиз... это то что пользователям отгружают, или это то что программисты компилируют?
Если это пользователям отгружают, то решение признает менеджер ответственный за проект, и любой "подход" в итоге будет послан им со словами "иначе меня заказчик убъет."
А если это то что программисты делают (далее идет на тестирование и далее по циклу), то если описание политики этого действа не умещается в несколько строчк — то она работать на будет.
Тут стоить определить несколько вещи, (я буду называть такой релиз сборкой):
— когда производиться сборка
— из каких исходных текстов производится сборка
— куда кладется результат сборки
— кто ответственный за проведение сборки
— что делается если сборка не удалась.
Например:
— сборка производиться ежедневно в 10.00
— сборка производится из последнего среза системы контроля версий
— результат сборки кладется на ftp сервер ftp.sourceofevil.whitehouse.gov в каталог \\u01\share\xxxfiles\hardporno\release\<номер версии>\
— за сборку отвечает назначенный программист
— в случае неудачи сборки (в том числе провала unit тестов), программист занесший файлы последним, назначается новым ответственным за сборку.
Это получился подход к компоновке и сборке.
Осталось тестирование, тут тоже нужно договориться:
— какая периодичность цикла тестирования
— кто ответственный за тестирование
— куда заносятся результаты тестирования
Tyo>Начальство требует изготовить по неск. проектам документ под названием "Политика релизов". Tyo>Среди прочих там дб пункты Tyo>- подход к компоновке релиза Tyo>- подход к сборке релиза Tyo>- подход к тестированию релиза
Не определены термины "компоновка" и "сборка". Что имеется в виду? спросите начальство.
Не определен даже термин "релиз". Что это такое? билд, переданный в тестирование? билд, выпущенный кастомерам?
Давайте для начала определим, что есть релиз. Как минимум очевидно, что релиз — это релиз продукта как целого, а продукт состоит из компонент. Следовательно, релиз продукта — это совокупность неких билдов его компонент, а значит, возникает задача интеграции, и зачастую интеграционного тестирования, и отслеживания статуса по тем фичам, которые требуют реализации в более чем одной компоненте.
Создание релиза включает в себя как техническую сторону дела, так и административную.
Техническая сторона — это список требований по операциям с сорс-контролом при создании релиза, по построению каждой компоненты, по интеграции дистры продукта из компонент, по обязательному циклу тестирования каждого релиза.
Административная сторона — это список требований к состоянию кода, в релиз попадающего. Требования, например, к оттестированности этого кода.
Здравствуйте, Tyo, Вы писали:
Tyo>Начальство требует изготовить по неск. проектам документ под названием "Политика релизов". Tyo>Среди прочих там дб пункты Tyo>- подход к компоновке релиза Tyo>- подход к сборке релиза Tyo>- подход к тестированию релиза
Возможно ваше начальство интересует процесс планирования и выпуска релиза. Опишите как вы соотносите требования/запросы на изменения с релизами (в частности есть ли у вас CCB и регламент его "заседаний"), далее опишите процедуру выпуска релиза (процесс). Это покажет всем заинтересованным сторонам то, как вы выпускаете релизы, что в свою очередь позволит оценить риски выпуска.
