Эта статья будет полезна тем, у кого разрабатывается десктопный продукт, распространяемый через инет-магазин.
Компания Conquest Software Solutions вышла на рынок с одним десктопным продуктом в 2002 году, с 2005 года стала продавать его через свой сайт, а с 2007 расширяла линейку продуктов. На сегодняшний день это 4 (SD, CS, CDB, FADEX) платных продукта, 1 (DV) бесплатный вспомогательный и 2 веб-продукта (site, WDV). Публикация некоторых из них всегда связана с дочерними, но в основном шаги к успешной публикации одинаковы. Несколько вариантов установки и обновления продукта упрощают работу конечному пользователю, но в теже несколько раз усложняют уровни проверок при публикации. Если в день получения бага от юзера тестировщик - это его адвокат, то в день выпуска QA становится на тёмную сторону и готов быть не только судьёй, но и прокурором для всех юзеро-хотелок.
До тех пор, пока публикацией заведовали только единственный тестировщик и единственный веб-разработчик, процесс протекал без сбоев. Но случалось так, что у кого-то был отпуск, а выложить билд надо было срочно. Тогда процесс не соблюдался в точности, потому что план действий лежал только в голове тестировщика, а веб-программист нажимал кнопки по его запросу. В итоге, конечный пользователь испытал проблемы со скачкой.
Шеф однажды спросил у меня, почему когда я выкладываю билды, то юзер никогда не жалуется. Мой ответ был прост: действия отработаны до автоматизма, и в день билда на листочке с Release Notes публикуемого продукта все пройденные этапы из моей головы перекочевывали на визуальный элемент. К сожалению, хоть и некоторые шаги были одинаковы для продуктов или типов (официальный, бета, специальный) билдов, но автоматизировать процесс даже частично было не на чем (фин.директор жадничал на тулзы, а бесплатных для самописных Delphi-элементов не было и нет). Тогда шеф решил частично помочь. Поскольку BTS у нас была самописная, то в Oracle базе он добавил таблицы, столбцы и триггеры на них, то есть автоматически формируемый список шагов для публикации.
Шаги делились на период ДО закрытия сайта для заливки и ПОСЛЕ операционные. Один триггер срабатывал для таблицы билдов и версий в момент добавления планируемого выпуска: в таблицу чек-листа добавлялся стандартный набор записей с указанием порядка действий для публикации определённой версии. В день публикации выпускающие тестировщик и программист проставляли дату-время каждой записи. Это значительно уменьшило количество проблем "заместителям публикаторов". А когда весь список очищался (таблица велась в "SD/Built-In VCS/SmartDataset" и активно использовались встроенные утилиты редактирования и фильтрации), то срабатывал следующий триггер, отправлявший e-mail нотификации руководству и иным заинтересованным лицам об успешном окончании работ с подробной инфой о выпущенном билде.
На момент создания первого чек-листа выпуска он состоял из десятка пунктов, в основном касающихся сайта. Но со временем этот список стал пополняться и детализироваться проверками инсталлятора, апдейтера, лицензионных артефактов. Необходимость в расширении списка диктовалась процессом разработки, который касался различных сторон продуктов и сайта. Несколько систем апдейта (с сайта, из файловой системы, через инсталлятор или OSD Updater), заказанные пользователями, частая смена лицензирования, улучшения в системных требованиях увеличивали и количество пунктов чек-листа. Большей частью пункты дробились и конкретизировались.
С расширением штата и переходом на Jira+Confluence ведение чек-листа обзавелось документацией.
К сожалению, в Jira 2014 года не существовало аналога нашим чек-листам. Поэтому решено было оформлять задачи типа TASK (Feature, Improvement, Bug не очень подходили по стилистике, к тому же фича чек-боксов Jira Plug-in TODO была возможна только для одного типа задач) в каждом из выпускаемых продуктов.
Для удобства работы были одобрены следующие мои предложения по оформлению задачи:
- Product = [ProductName]. Для каждого продукта создавались свои задачи, в префиксе которых значились буквы короткого имени продукта, но они же дублировались и в Summary для упрощения фильтрации;
- Summary оформляется по формату "Publish [ShortProductName] [Major].[Minor].[Release] [major|minor|release|spec-build|fix-build] [official|beta]". По короткому имени задачи было ясно, что конкретно будет публиковаться - бета или спец.билд, новая версия или текущие исправления. Например, "Publishing SD 4.7.2 release official" - публикация всем второго релиза платной версии 4.7 продукта SQLDetective, "Publishing SD 5.0.1b spec-build" - выкладывание специального билда бета-версии 5.0 продукта SQLDetective;
- Type = "TASK". К сожалению, только для одного типа задач админ Jira смог прикрутить поле TODO;
- Priority = "Major". Важность задачи велика, но не критична и не блокирует иную работу. К тому же есть дополнительное поле Business Value с самым высоким значением;
- Affected Versions = [LastPublishedBuild]. Последний опубликованный билд давал информацию всем заинтересованным сторонам: скрам-мастер подбирал задачи для бэклога и отчитывался перед вышестоящими, исходя из дат билдов опубликованного ранее и текущей; тех.писатель собирал выполненные задачи для Release Notes, отсекая временные; выпускающий тестировщик ориентировался с билдами и версиями для проверок апдейтера;
- Labels = "internal". Задача не должна входить ни в какие RN и для этого фильтруется лейблой;
- Status меняется по стандартному workflow: создаётся со значением Open; когда становится известна дата публикации, то меняется на Planned и заполняется поле Due Date (эти же данные используются для пина в Slack); процесс публикации сопровождается статусами In Progress + Testing; и финализируется Done|Close;
- Component = "Core". У каждого продукта обязательно существует модуль Core;
- Description = Summary + некоторые детали или примечания об особенностях публикации (кому спец.билд);
- Assignee = выпускающий тестировщик. Хоть в выпуске и участвует несколько членов команды, но большинство шагов исполняет именно тестировщик. На него же и запишется всё время работы - чаще это один рабочий день, если не случалось откатов билда и завершения работ в иной день;
- TODO = чек-лист шагов публикации, выстроенные в порядке исполнения и с префиксами для задействованных членов команды: PT=ProductTester, WT=WebTester, PD=ProductDeveloper, WD=WebDeveloper, TW=TechWriter, DO=DevOps, PM= ProductManager. Пример и подробности будут чуть ниже, а пока немного примечаний. В Confluence поначалу была оформлена таблица с полным списком, их пояснениями и отметками для типов публикаций (официальная, бета, спец.билд), а позже для ускорения работы были созданы конкретные списки по продуктам. Но в них отпала необходимость, когда была освоена фича Jira по клонированию задач. Сразу после окончания публикации (потом и в сам список этот шаг был записан) уже закрытую задачу клонировали и редактировали следующие поля: Affected Versions = только что опубликованный билд; обнулялись чекеры TODO и поля Issue Links, Fixed Versions, Due Date; в Summary и Description увеличивался номер версии. Время от времени список актуализировался, поскольку некоторые процессы удавалось нивелировать (форматирование текстов RNs, LicAgreement, ReadMe в разных форматах - txt, rtf, doc) или автоматизировать (генерация SampleDocu, очистка компа, проверка подписи файлов), или убедить РМ в избыточности и отказаться от объёмных проверок (нагрузочные тесты очень долго были в первых шагах), заменив на более нужные (результаты проверки сайта фиксировались прикреплением скриншотов) или новые (техпрогресс расширял области применимости продуктов, а значит и увеличивал количество багов). Необходимость детализации и разбиения на мелкие шажки усугублялась после очередных "пинков" следующему публикатору, которому приходилось ещё и ещё раз пояснять смысл и назначение чека. А точный порядок шагов сократил сообщения в чате, где передавалась очерёдность, с трёхстрочных до одной фразы "твой ход". А он уже открывал задачу с чек-листом и видел не проставленные чеки, точно зная, что от него ждут. Единственная проблема - после проставления каждого чека необходимо было выполнять сохранение в базу Jira, а иначе очерёдник либо не увидит ваших чекеров, либо ставя свои затрёт ваши;
- Issue Links = список задач, прилинкованных по типу "blocks the TASK", без закрытия которых нельзя начинать публикацию. В простонародье эта часть звалась "КакогоБагаБилд". Поскольку РМ в Jira Structure планировал и отслеживал только Features+Improvements, то включаемые в билд баги решено было мной линковать к этой задаче. И поскольку возможности Jira ограничивались показом только первых пяти прилинкованных, то во время работы (за несколько дней до публикации тестировались именно эти блокеры чек-листа публикации) неудобство просмотра объёма незавершённых работ исправлялось обычной отлинковкой. Принцип сокращения списка был взят мной из самописной BTS, где у меня была отфильтрована база по запланированным на тестирование задачам и без даты окончания теста. Привычка - вторая натура, поэтому и блокеры выкидывались за ненадобностью. Но со временем команда стала извлекать из такой линковки свою выгоду: РМ стал отчитываться руководству по списку блокеров, техписатель фильтровала исправленные баги для написания RNs, программисты опирались на список блокеров только для оправдания занятости хот-багами вместо текущих разработок, группа веба опиралась только на этот список из-за невозможности включить их задачи в автобилдер. Единственная задача, которую никогда не выкидывали из списка блокеров, была с полным отредактированным текстом RNs, поскольку именно их впиливали в билд в последнюю очередь и пересобирали продукт. Видели бы вы глаза представительницы Atlassian на конференции SQADays-21, когда ей были описаны эти "танцы с бубнами" вместо полноценного использования Jira Structure. Но РМ ни за какие коврижки не соглашался вести бэклоги фикс-билдов с одними только багами в "его" Jira Structure, даже после моего рассказа о том, что бэклоги можно делать составными и отчитываться более точно руководству о затраченных усилиях. Из-за его упрямства команда только ещё больше отстраняла тестировщиков от программистов: спрос за импрувы (велись в Jira Structure) был с программистов, спрос за баги (велись блокерами чек-листа) был с тестировщиков. То есть в команде всегда было два разных бэклога, а не единый. Единственным аргументом было то, что баги никогда не проходили стадии эстимации, поскольку проггеры о багах отзывались: "Баг от импрува отличается тем, что его быстрее исправить, чем понять по тексту сколько это займёт времени", и никогда не планировали их или декомпозировали;
- Fixed Versions = публикуемый билд (четырёхзначная версия) выбирается во время закрывания задачи, а на момент оформления ставилась трёхзначная версия без указания билда. Она использовалась для планирования и иной фильтрации.
Если у вас до сих пор не было чек-листа публикации или вы не обращали внимания на необходимость проверять что-то из вышеизложенного списка, то сейчас наступило время для актуализации вашего списка шагов публикации. Благодаря наличию задач публикаций вся команда может видеть долгосрочные планы:
Пока RNs собирались вручную и хелп-примеры готовил первый член команды, публикация была неожиданностью для всех:
или
Приучив всех выпускающих к строгому порядку чек-листа процесс публикации стал проходить незаметно для всей команды, и в чате среди прочей болтовни можно было заметить:
или
Со временем шефу скучно стало ждать выпуска и моё предложение использовать канал билдов для связи в день публикации было поддержано:
И процесс потёк, как по маслу:
Новичков вливали постепенно:
или
Позже шеф просто умилялся:
Бывало, конечно, что новички, стесняясь общего канала, молча проставляли чеки. Тогда РМ дёргал весь отдел качества фразой: "Что там с выпуском? Почему тишина?" и приходилось его "посылать" в Jira, дабы не отвлекать народ от важных дел.
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!
И укладывались в ровно отведённый час. Перевыпуски, конечно, случались, но никак не по причине пропуска какого-то пункта публикации.
Компания Conquest Software Solutions вышла на рынок с одним десктопным продуктом в 2002 году, с 2005 года стала продавать его через свой сайт, а с 2007 расширяла линейку продуктов. На сегодняшний день это 4 (SD, CS, CDB, FADEX) платных продукта, 1 (DV) бесплатный вспомогательный и 2 веб-продукта (site, WDV). Публикация некоторых из них всегда связана с дочерними, но в основном шаги к успешной публикации одинаковы. Несколько вариантов установки и обновления продукта упрощают работу конечному пользователю, но в теже несколько раз усложняют уровни проверок при публикации. Если в день получения бага от юзера тестировщик - это его адвокат, то в день выпуска QA становится на тёмную сторону и готов быть не только судьёй, но и прокурором для всех юзеро-хотелок.
До тех пор, пока публикацией заведовали только единственный тестировщик и единственный веб-разработчик, процесс протекал без сбоев. Но случалось так, что у кого-то был отпуск, а выложить билд надо было срочно. Тогда процесс не соблюдался в точности, потому что план действий лежал только в голове тестировщика, а веб-программист нажимал кнопки по его запросу. В итоге, конечный пользователь испытал проблемы со скачкой.
Шеф однажды спросил у меня, почему когда я выкладываю билды, то юзер никогда не жалуется. Мой ответ был прост: действия отработаны до автоматизма, и в день билда на листочке с Release Notes публикуемого продукта все пройденные этапы из моей головы перекочевывали на визуальный элемент. К сожалению, хоть и некоторые шаги были одинаковы для продуктов или типов (официальный, бета, специальный) билдов, но автоматизировать процесс даже частично было не на чем (фин.директор жадничал на тулзы, а бесплатных для самописных Delphi-элементов не было и нет). Тогда шеф решил частично помочь. Поскольку BTS у нас была самописная, то в Oracle базе он добавил таблицы, столбцы и триггеры на них, то есть автоматически формируемый список шагов для публикации.
На момент создания первого чек-листа выпуска он состоял из десятка пунктов, в основном касающихся сайта. Но со временем этот список стал пополняться и детализироваться проверками инсталлятора, апдейтера, лицензионных артефактов. Необходимость в расширении списка диктовалась процессом разработки, который касался различных сторон продуктов и сайта. Несколько систем апдейта (с сайта, из файловой системы, через инсталлятор или OSD Updater), заказанные пользователями, частая смена лицензирования, улучшения в системных требованиях увеличивали и количество пунктов чек-листа. Большей частью пункты дробились и конкретизировались.
С расширением штата и переходом на Jira+Confluence ведение чек-листа обзавелось документацией.
- Product = [ProductName]. Для каждого продукта создавались свои задачи, в префиксе которых значились буквы короткого имени продукта, но они же дублировались и в Summary для упрощения фильтрации;
- Summary оформляется по формату "Publish [ShortProductName] [Major].[Minor].[Release] [major|minor|release|spec-build|fix-build] [official|beta]". По короткому имени задачи было ясно, что конкретно будет публиковаться - бета или спец.билд, новая версия или текущие исправления. Например, "Publishing SD 4.7.2 release official" - публикация всем второго релиза платной версии 4.7 продукта SQLDetective, "Publishing SD 5.0.1b spec-build" - выкладывание специального билда бета-версии 5.0 продукта SQLDetective;
- Type = "TASK". К сожалению, только для одного типа задач админ Jira смог прикрутить поле TODO;
- Priority = "Major". Важность задачи велика, но не критична и не блокирует иную работу. К тому же есть дополнительное поле Business Value с самым высоким значением;
- Affected Versions = [LastPublishedBuild]. Последний опубликованный билд давал информацию всем заинтересованным сторонам: скрам-мастер подбирал задачи для бэклога и отчитывался перед вышестоящими, исходя из дат билдов опубликованного ранее и текущей; тех.писатель собирал выполненные задачи для Release Notes, отсекая временные; выпускающий тестировщик ориентировался с билдами и версиями для проверок апдейтера;
- Labels = "internal". Задача не должна входить ни в какие RN и для этого фильтруется лейблой;
- Status меняется по стандартному workflow: создаётся со значением Open; когда становится известна дата публикации, то меняется на Planned и заполняется поле Due Date (эти же данные используются для пина в Slack); процесс публикации сопровождается статусами In Progress + Testing; и финализируется Done|Close;
- Component = "Core". У каждого продукта обязательно существует модуль Core;
- Description = Summary + некоторые детали или примечания об особенностях публикации (кому спец.билд);
- Assignee = выпускающий тестировщик. Хоть в выпуске и участвует несколько членов команды, но большинство шагов исполняет именно тестировщик. На него же и запишется всё время работы - чаще это один рабочий день, если не случалось откатов билда и завершения работ в иной день;
- TODO = чек-лист шагов публикации, выстроенные в порядке исполнения и с префиксами для задействованных членов команды: PT=ProductTester, WT=WebTester, PD=ProductDeveloper, WD=WebDeveloper, TW=TechWriter, DO=DevOps, PM= ProductManager. Пример и подробности будут чуть ниже, а пока немного примечаний. В Confluence поначалу была оформлена таблица с полным списком, их пояснениями и отметками для типов публикаций (официальная, бета, спец.билд), а позже для ускорения работы были созданы конкретные списки по продуктам. Но в них отпала необходимость, когда была освоена фича Jira по клонированию задач. Сразу после окончания публикации (потом и в сам список этот шаг был записан) уже закрытую задачу клонировали и редактировали следующие поля: Affected Versions = только что опубликованный билд; обнулялись чекеры TODO и поля Issue Links, Fixed Versions, Due Date; в Summary и Description увеличивался номер версии. Время от времени список актуализировался, поскольку некоторые процессы удавалось нивелировать (форматирование текстов RNs, LicAgreement, ReadMe в разных форматах - txt, rtf, doc) или автоматизировать (генерация SampleDocu, очистка компа, проверка подписи файлов), или убедить РМ в избыточности и отказаться от объёмных проверок (нагрузочные тесты очень долго были в первых шагах), заменив на более нужные (результаты проверки сайта фиксировались прикреплением скриншотов) или новые (техпрогресс расширял области применимости продуктов, а значит и увеличивал количество багов). Необходимость детализации и разбиения на мелкие шажки усугублялась после очередных "пинков" следующему публикатору, которому приходилось ещё и ещё раз пояснять смысл и назначение чека. А точный порядок шагов сократил сообщения в чате, где передавалась очерёдность, с трёхстрочных до одной фразы "твой ход". А он уже открывал задачу с чек-листом и видел не проставленные чеки, точно зная, что от него ждут. Единственная проблема - после проставления каждого чека необходимо было выполнять сохранение в базу Jira, а иначе очерёдник либо не увидит ваших чекеров, либо ставя свои затрёт ваши;
- Issue Links = список задач, прилинкованных по типу "blocks the TASK", без закрытия которых нельзя начинать публикацию. В простонародье эта часть звалась "КакогоБагаБилд". Поскольку РМ в Jira Structure планировал и отслеживал только Features+Improvements, то включаемые в билд баги решено было мной линковать к этой задаче. И поскольку возможности Jira ограничивались показом только первых пяти прилинкованных, то во время работы (за несколько дней до публикации тестировались именно эти блокеры чек-листа публикации) неудобство просмотра объёма незавершённых работ исправлялось обычной отлинковкой. Принцип сокращения списка был взят мной из самописной BTS, где у меня была отфильтрована база по запланированным на тестирование задачам и без даты окончания теста. Привычка - вторая натура, поэтому и блокеры выкидывались за ненадобностью. Но со временем команда стала извлекать из такой линковки свою выгоду: РМ стал отчитываться руководству по списку блокеров, техписатель фильтровала исправленные баги для написания RNs, программисты опирались на список блокеров только для оправдания занятости хот-багами вместо текущих разработок, группа веба опиралась только на этот список из-за невозможности включить их задачи в автобилдер. Единственная задача, которую никогда не выкидывали из списка блокеров, была с полным отредактированным текстом RNs, поскольку именно их впиливали в билд в последнюю очередь и пересобирали продукт. Видели бы вы глаза представительницы Atlassian на конференции SQADays-21, когда ей были описаны эти "танцы с бубнами" вместо полноценного использования Jira Structure. Но РМ ни за какие коврижки не соглашался вести бэклоги фикс-билдов с одними только багами в "его" Jira Structure, даже после моего рассказа о том, что бэклоги можно делать составными и отчитываться более точно руководству о затраченных усилиях. Из-за его упрямства команда только ещё больше отстраняла тестировщиков от программистов: спрос за импрувы (велись в Jira Structure) был с программистов, спрос за баги (велись блокерами чек-листа) был с тестировщиков. То есть в команде всегда было два разных бэклога, а не единый. Единственным аргументом было то, что баги никогда не проходили стадии эстимации, поскольку проггеры о багах отзывались: "Баг от импрува отличается тем, что его быстрее исправить, чем понять по тексту сколько это займёт времени", и никогда не планировали их или декомпозировали;
- Fixed Versions = публикуемый билд (четырёхзначная версия) выбирается во время закрывания задачи, а на момент оформления ставилась трёхзначная версия без указания билда. Она использовалась для планирования и иной фильтрации.
| Примерный список чекеров (поле TODO) | Пояснения (статья в Confluence) |
|---|---|
| PT_All planned bugs fixed? | Проверить список багов - блокеров публикации, запланированных на фиксирование, и разработок из Structure |
| PT_Smoke tested? | После инсталляции проверить основной функционал на триальном и лицензионном ключе. |
| PT_Internal files in the setup program are correct and they are enough for first start or update, upgrade? | Проверить корректность и достаточность служебных файлов для инсталляции и апдейта |
| PT_The setup program tested against all supporting OS? | Проверить инсталляцию и открытие приложения на всех ОС из списка System Requirements |
| PT_Stress test passed? | Шеф не различал нагрузочные и стресс-тесты, а также слышать не хотел, что для тестирования больших данных нужно много времени. На выпуск давался только один день, и он наивно полагал, что мы проверяли обработку монстров на выпускаемом билде. Очевидно, что подобному пункту не место в чеклисте. Но если у вас есть автоматизтрованные регресс-тесты, которые выполняются за минимальное время, то слово stress меняйте на regress и смело оставляйте. |
| PT_DemoProject or SampleDocus included into installer and updater? | Примеры использования продукта включены в инсталятор, апдейтер. Версия примеров актуальная. Проверку этого пункта вполне можно совместить с иными (smoke, инсталлятор с ключом, апдейтер и апгрейд) |
| PT_Copyright date correct in the program, readme file? | Имя компании и год лицензирования проверить в файлах и интерфейсе продукта (About, Welcome Window, Preferences, ReadMe, …) |
| PT_The setup program correctly shows the program name, default installation path, etc.? The setup program shows "beta" in the program name and installs to the beta folder? | Проверить инсталлятор на корректность имени проги, установочного каталога, иконок., префиксы beta и др. Проверить инсталляцию на чистую машину(предварительно почистить реестр и папки ОС), на имеющуюся старую версию. |
| PT_License agreement file in the setup program is for an official/beta version? It's the latest version. | Проверить текст лицензионного соглашения на отсутствие/наличие Beta примечаний |
| PT_Release notes shown in the application on first start up? | "What’s New?" показывается при первом запуске нового приложения |
| PT_Readme file in the setup is for an official/beta version? | Проверить файл ReadMe на отсутствие/наличие Beta примечаний |
| PT_The trial key file in the setup program is for an official/beta version? | Проверить наличие и длительность триального ключа в файле инсталлятора и апдейтах |
| PT_Check license limits: trial, after trial, lic numbers. | Проверить триальный ключ на ограничения в период действия и вне его пределов, лицензионный ключ на количество юзеров при совместной работе. |
| PT_All executible files, including updater and installer e-signed? | Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении имеют электронную подпись |
| PT_All files checked by several antiviruses? | Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении не имеют препятствий антивирусами |
| WD_Close site. Make back-up. | Закрыть сайт для доступа обычным юзерам и сохранить копии заливаемых страниц и прочих файлов. Начало заливки считалось по американскому времени (для Москвы это 16-00). Все предыдущие пункты выполнялись с 10-00 утра (автосборка утреннего билда) до 15-00 или 16-00 часов дня, при сбоях билд пересобирался или сообщалось шефу о стоп-билде. |
| WD_All pages and child sites are updated? The product teaser on the website shows correct product version? | Каждый продукт имеет свою первоначальную страницу и коротко-названные сайты, которые надо обновлять самостоятельно. Некоторые продуктовые рекламные заставки могут размещаться на общих сайтовых страницах, но должны быть актуальны |
| WD_The setup file uploaded to the website? | Инсталлятор залит на сайт. Проверить скачивание через страницы Free Download, Upgrade/Update или Buy Online. Веб-разработчик обычно единым шагом заливал инсталляторы и апдейтеры во все места, менял номер версии и оформлял RNs. Так что разбивка сайтовских пунктов больше касалась веб-тестировщика. |
| WD_The OSD updates uploaded to the website? The OSD updates uploaded to the website to both folders (non-beta and beta if it's official publishing)? | Апдейты загружены на сайт. Проверить OSD Updater на скачивание Core и Kits, апдейт с беты на официальную |
| WT_Website pages and news ready? All modified webpages copied from the test website to the live website? | Веб-разработчик заливает обновления страниц сайта, а веб-тестировщик проверяет готовность сайта |
| WT_Copyright date correct in website? | Имя компании и год лицензирования проверить на сайте, прикрепить скриншоты |
| WT_Release notes availabe on the website? | Зайти на сайт и найти соответствующие выпускаемому билду Release Notes, сделать скриншот и прикрепить его к таске публикации. |
| WT_License is the same in website (updater from site) and application (installer, updater from file system, About). | Тексты лицензионного соглашения идентичны на сайте, в инсталляторе, апдейтере, продукте. |
| WT_The setup program available to download, correct and can be installed? Renaming folders enabled? | Скачать с сайта инсталляционный файл и установить на чистую машину, на старую версию в триале и лицензионно, проверить смену имён папок |
| WT_KeyGen works for current version? New key delivired? KeyDeliveryProcs includes data from the previous version? | Генератор ключа на сайте формирует файл для текущей версии и отправляет линки или сам файл всеми задуманными способами, смена версии продукта или генератора ключа не препятствует процессу обновления |
| PT_Release notes availabe in OSD Updater? | Запустить OSD Updater и проверить наличие Release Notes текущей и промежуточных версий. |
| PT_BETA release notes not visible in OSD Updater? | OSD Updater не должен показывать Release Notes для Beta версии, если выпуск официальной. В бета-версии должны быть видны RNs официальной и беты. |
| PT_OSD Updater updates the previous official/beta version to the new version? The product version on the website displayed correctly? | Проверить возможность апгрейда со старой версии триально и лицензионно, из файловой системы и с сайта. В личном кабинете юзера на сайте и в общедоступных местах скачивания актуализирована версия продукта |
| WD_Open site. | Обычно заливка и проверка обновлений через сайт занимала около часа времени, поэтому в 17-00 (окончание рабочего дня в Москве и 9 утра в Америке) можно было открывать сайт и рапортовать руководству об успешной публикации |
| DO_VCS branched, Slack pins updated, Jira builds updated, Installers renamed? | По окончании работы с опубликованным билдом начинается работа со следующим: разветвляется СКВ кода, в чате и на доске версий БТС убираются выполненные задачи и оформляются новые, в файловой системе перименовываются инсталляторы (добавляется постфикс "_р" - public) |
| TW_Wiki topics updated? | Одно время тех.писатель вела топики в Wiki и актуализировала инфу о доступных версиях, фичах. Но редакторы Wiki запретили эти статьи, т.к. они стали более рекламными, нежели информационными. |
Пока RNs собирались вручную и хелп-примеры готовил первый член команды, публикация была неожиданностью для всех:
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!
И укладывались в ровно отведённый час. Перевыпуски, конечно, случались, но никак не по причине пропуска какого-то пункта публикации.
Комментариев нет:
Отправить комментарий