Что такое релиз программы

Содержание

Система программ 1С:Предприятие включает большое количество программных продуктов. При этом практически все продукты периодически обновляются. Пользователь, работающий с лицензионной версией программы, имеет возможность получать обновления. В этой статье мы опишем, какие бывают обновления, как они называются и чем отличаются. Этот и другие интересные материалы для пользователей «1С:Предприятия» размещены в очередном выпуске Информационно-технологического сопровождения (на диске ИТС).

Как обновить свою программу?
Что такое «версия» программы?
Что такое «редакции»?
Что такое «релиз (выпуск)»?
Где получить информацию о выходе обновлений?

Эта информация необходима для того, чтобы понимать, как и какие части 1С:Предприятия необходимо обновлять, а также для того, чтобы при обращении в службу технической поддержки фирмы «1С» пользователь мог точно сообщить, с каким программным продуктом он работает. Информация о том, какие обновления установлены, существенно повышает эффективность консультации.

Словарь музыкального менеджмента. Р — релиз.

Прежде всего отметим, что 1С:Предприятие состоит из платформы (системной части) и различных конфигураций. Платформа поставляется всегда в готовом виде и не может быть изменена пользователем. Конфигурация также поставляется в готовом виде, но может изменяться пользователем (кроме базовых версий). В поставку большинства программных продуктов 1С:Предприятия входит платформа и одна или несколько конфигураций. Некоторые конфигурации поставляются отдельно, и для их работы у пользователя должен быть другой продукт, включающий платформу.

Платформа и конфигурации обновляются независимо, то есть обновления платформы и конфигурации выпускаются в разное время и имеют разные номера. Однако в некоторых случаях необходимо выполнять обновление и платформы, и конфигурации. Данное обстоятельство обычно оговаривается в инструкции по обновлению конфигурации.

Получение обновлений

Существует несколько способов получения обновлений.

Наиболее эффективный способ — это подписка на диск ИТС (диск Информационно-технологического сопровождения). Диск (CD_ROM) выпускается раз в месяц и содержит, помимо большого количества методического и нормативно-справочного материала, текущие обновления — как конфигураций, так и платформы. Подписка на диск ИТС включает доставку диска и установку обновлений. Для подписчиков диска ИТС также вводится возможность получения обновления конфигураций с Web-сайта фирмы «1С».

Получение обновлений может выполняться у партнеров фирмы «1С». Возможность и условия обновлений следует обговаривать с конкретной партнерской организацией.

Зарегистрированные пользователи могут также получать обновления непосредственно в фирме «1С».

Не рекомендуется пользоваться неофициальными источниками для получения обновлений.

Установка обновлений

Установка новых версий программы выполняется достаточно редко и подробно описывается в прилагаемой документации.

Релиз программы 1С: Бухгалтерия 8 номер 2.0.44

Установка релизов платформы выполняется аналогично первоначальной установке программы. Обновление представляет собой обычный дистрибутив (запись программы, предназначенная для установки) — такой же, как в комплекте поставки или специальный дистрибутив с диска ИТС. Установка с обычного дистрибутива ничем не отличается от первичной установки, а установка с диска ИТС автоматически находит программу, установленную на компьютере, и выполняет установку. При установке релиза платформы неважно, какой релиз был установлен до этого.

Обновление конфигураций (редакций и релизов) должно выполняться согласно инструкции. Для типовых конфигураций инструкция по установке выдается в процессе установки новой редакции или релиза конфигурации. В состав конфигурации включается также и описание изменений, внесенных в данном релизе или редакции. Обновление конфигурации следует выполнять весьма внимательно.

Рекомендуется до выполнения обновления сделать резервную копию информационной базы. При установке обновлений конфигураций следует придерживаться той последовательности, в которой выпускаются релизы и редакции. Так как при установке каждого релиза может выполняться конвертация информации, то для более корректного обновления не следует пропускать релизы.

На диске ИТС существует раздел с подробными рекомендациями по обновлению конфигураций.

Как обновить свою программу?

Получение обновлений

Существует несколько способов получения обновлений.

Зарегистрированные пользователи могут также получать обновления непосредственно в фирме «1С».

Не рекомендуется пользоваться неофициальными источниками для получения обновлений.

Установка обновлений

Что такое «версия» программы?

В системе программ 1С:Предприятие понятие «версия» относится к платформе. Версия является своего рода «поколением» системы программ. Новая версия выпускается раз в несколько лет и является существенным развитием практически всех возможностей системы. Текущей версией 1С:Предприятия (на апрель 2001 года) является версия 7.7.

По имени этой версии именуются и все продукты, выпускаемые с момента выхода данной версии. Например, 1С:Бухгалетерия 7.7, включает платформу 1С:Предприятия версии 7.7 и типовую конфигурацию, разработанную для этой версии. Конфигурации, разработанные для предыдущих версий, могут использоваться с данной версией, но только после выполнения конвертации (преобразования самой конфигурации и данных).

Номер версии указывается и на коробке, и в книжке. В самой программе его можно посмотреть в режиме «Помощь — О программе» — в верхней строке диалога. Для версии 7.7 там должно быть написано «1С:Предприятие 7.7 …». Далее может быть уточнение варианта платформы, например, «для SQL».

Заметим, что слово «версия» в 1С:Предприятии используется и для обозначения варианта поставки, например, «базовая», «сетевая», «стандартная», «для SQL» и т. д. Однако версия в этом смысле не влияет на обновление программы — это именно варианты поставки программного продукта (подробнее варианты поставки были описаны нами в № 1 «БУХ.1С» за 2001 год, а также содержатся в разделе «Различия программных продуктов системы программ «1С:Предприятие» диска ИТС).

Что такое «редакции»?

Понятие «Редакция» в системе программ 1С:Предприятие применяется к конфигурациям. Новые редакции конфигураций разрабатываются в среднем раз в полгода и являются развитием конкретной конфигурации. В новых редакциях расширяется состав задач, решаемых программой, вводятся новые возможности (документы, справочники, отчеты), улучшаются алгоритмы и внешнее оформление.

В некоторых случаях выпуск новых редакций обусловлен существенными изменениями законодательства, требующими перестройки механизмов учета. Новая редакция, как правило, имеет новую документацию. Кроме того, новая редакция обычно содержит описание отличий для пользователей предыдущих редакций. При переходе на новую редакцию требуется выполнить определенную процедуру установки, которая может выполняться с конвертацией данных или без нее в зависимости от характера развития конфигурации.

Номер редакции обычно не включается в название самого продукта, но указывается в названии книги, описывающей работу с типовой конфигурацией. В самой программе номер редакции можно посмотреть в режиме «Помощь — О программе». После слова «Конфигурация» располагается название конфигурации и номер редакции.

В некоторых конфигурациях номер редакции может не отображаться в режиме «О программе». Помимо этого, для некоторых конфигураций (например, «Зарплата + Кадры») понятие редакции не используется.

Что такое «релиз (выпуск)»?

Термин «релиз» (от английского «release» — «выпуск») используется в компьютерной индустрии для обозначения обновления программы, незначительно отличающегося от предыдущего. В 1С:Предприятии понятие «релиз» применяется для обозначения текущего обновления как платформы так и конфигурации. Соответственно бывают релизы платформы, а бывают релизы конфигураций. Релиз не является существенным развитием программы. В основном выпуски релизов связаны с исправлением обнаруженных ошибок или изменениями, внесенными в соответствии с вышедшими нормативными актами.

Обновление релиза платформы выполняется достаточно просто. Конвертация данных при этом не производится. Обновление релиза конфигурации выполняется по прилагаемой инструкции. В зависимости от сделанных в релизе изменениях при обновлении может потребоваться или не потребоваться конвертация данных.

Номера релизов не печатаются в документации или каких-либо других печатных материалах. Номера релизов можно посмотреть в самой программе в режиме «Помощь — О программе». Номер релиза платформы выводится в скобках справа от названия и номера версии платформы, а номер релиза конфигурации выводится в скобках справа от названия и номера конфигурации.

В некоторых конфигурация номер релиза может не отображаться в режиме «О программе».

Где получить информацию о выходе обновлений?

Выход новых версий платформы и редакций конфигураций обычно освещается в прессе, на единых семинарах и других маркетинговых мероприятиях. Информация о выпуске новой версии или редакции можно посмотреть в новостях на Web-сайте фирмы 1С (www.1c.ru). Разумеется, эту информацию можно узнать у партнеров, занимающихся продажей и поддержкой программных продуктов фирмы «1С».

Выпуск релизов, как правило, не освещается в прессе. Информация о выходе релизов конфигураций регулярно публикуется на Интернет-ресурсе для бухгалтеров buh.1c.ru. Также информацию о выходе релизов можно получить в отделе технической поддержки фирмы 1С.

Источник: buh.ru

Что такое альфа- и бета-версии

Каждая программа перед тем, как попасть к пользователю, проходит несколько этапов тестирования. Но иногда пользователям могут быть доступны даже те версии, которые не протестированы до конца — и многие этому даже рады. Давайте разберёмся, как это работает.

Стадии тестирования и разработки софта

Если не углубляться в нюансы разработки и тестирования, то обычно говорят о пяти состояниях, в которых находится программа:

Преальфа (Pre-alpha) — самая начальная стадия разработки.
Альфа-версия — вроде всё сделали, протестировали самое основное.
Бета-версия — оттестировали большую часть, ловим тараканов при поддержке небольшого круга доверенных людей.
Релиз-кандидат — почти готовая к выпуску программа.
Релиз — готовая программа.

В теории софт должен пройти все стадии, прежде чем отправиться к пользователю. Но на практике бывает так, что люди годами могут пользоваться альфа-версией и это их устраивает. Или даже ждать выпуска преальфы, чтобы скорее воспользоваться новыми возможностями или получить эксклюзивный игровой контент. Всё зависит от целей и задачи программы (или игры).

Преальфа

Преальфа — это сырой продукт, не предназначенный для использования. На нём чаще всего тестируют гипотезы и убеждаются, что софт в принципе может работать.

Эта версия позволяет оценить выбранную архитектуру и подход к программированию, сравнить с планируемой нагрузкой и понять, идёт ли всё по плану или впереди будет гораздо сложнее. В преальфе много ошибок, заглушек и не предусмотренных тестами ситуаций.

Иногда преальфа нужна для того, чтобы показать клиентам или инвесторам, как вообще идут дела в компании. Например, в игровой индустрии ролики из преальфа-версии позволяют заранее прикинуть возможности графики в игре или понять, стоит вкладывать деньги в эту идею или она провалится в прокате.

Альфа

Когда программа доходит до стадии «альфа», то считается, что в ней реализованы все возможности, предусмотренные этой версией, и теперь нужно найти все ошибки.

Случается такое, что во время тестирования в программу добавляются или в ней сокращаются некоторые модули, чтобы снизить сложность или количество ошибок. Альфа-версия считается уже как бы рабочей, но очень сырой версией программы. По идее, ей уже можно пользоваться, но с поправкой на общую глючность.

Бета

Бета-версия — это уже серьёзно. Чаще всего это означает, что в ней исправлены почти все большие ошибки, но может остаться много мелких, которые ещё не нашли тестировщики.

Компания может выпустить бета-версию программы и для обычных пользователей. Например, она может давать к ней доступ в обмен на сообщения об ошибках — так пользователи раньше остальных получают новый продукт, а компания — бесплатных тестировщиков. Такой процесс тестирования называется открытым, потому что продукт открывается для всех желающих.

Ещё одна причина выпуска бета-версий в свет — желание компании уйти от ответственности за ошибки. Идея такая: компания говорит, мол, что это ещё не окончательная версия, поэтому в ней могут быть баги, которые ещё не отловили. Но на самом деле эту версию никто не будет дорабатывать до финала — в лучшем случае поправят пару заметных ошибок.

Релиз-кандидат

После бета-тестирования и исправления почти всех найденных ошибок, программа переходит в стадию релиз-кандидата. Это значит, что ей можно пользоваться как полноценной программой, но не факт, что тестировщики нашли все ошибки.

Если через 1–3 месяца полноценного использования и тестирования программы в ней не найдут никаких ошибок, программа переходит в стадию релиза.

Релиз-кандидат — это почти всегда та же самая программа, что и в релизе, просто разработчикам нужно убедиться, что она работает стабильно и без сбоёв.

Релиз

Релиз — это готовая версия программы, доступная для всех пользователей.

Релизом может быть и крупное обновление, например, новая версия Windows, а может быть и обновление с версии 1.5.234 на версию 1.5.235. Про то, что означают эти цифры и как они меняются, мы поговорим как-нибудь отдельно.

Источник: thecode.media

Всë, что вам нужно знать об управлении релизами

В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.

Что это такое управление релизом?

Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:

Планирование релиза
Сборка релиза
Приемочное пользовательское тестирование
Подготовка релиза
Развертывание релиза.

Планирование релиза

Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.

При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.

Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:

Отсечение: начинается 1-й день.
Внутреннее тестирование версий альфа/UAT: Три дня.
Поэтапное развертывание [1%] Представление на ревью.
Продолжительность ревью: 3 дня.
Один день при 20% пользователей.
Один день при 50% пользователей, в тот же день рост до 100% пользователей.

Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.

Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:

Сроки
Сроки поставки
Требования
Общий масштаб проекта

Как только план утверждается и окончательно оформляется, начинается самое интересное!

Важные аспекты планирования релизов

Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:

Релиз-менеджер управляет релизом и координирует его.
Мы принимаем только код с проведенным ревью и протестированный код.
В процессе есть этап внедрения.
Мы мониторим выпущенную версию приложения.

Построение релиза

После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.

В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.

Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.

Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.

Релиз веток и контроль версий

Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?

Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.

Пользовательское приемочное тестирование

Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.

Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:

Могут ли пользователи работать с приложением?
Соответствует ли поведение приложения ожиданиям?
Решает ли приложение проблему пользователей?

Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!

Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.

Подготовка и релиз

Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.

После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.

Развертывание релиза

Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:

Создание окончательной сборки [с указанием ветки и названия версии].
Добавление «What’s New» в релизе.
Добавление процента развертывания.
У каждого этапа есть ручной ввод сигналов (красный/зеленый) от каждой из команд [UAT, бенчмарк, производительность, автоматизация].

В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.

Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.

Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.

Анализ после релиза

Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.

Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.

Подведем итоги

Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:

Повысили нашу производительность за счёт улучшения коммуникации и координации.
Доставка наших релизов происходит быстрее, что также снижает риски. В этих изменениях участвует команда, которая может регулярно предоставлять качественные релизы с высокой скоростью.
Управление релизами также поддерживает систематизацию и оптимизацию метода разработки и эксплуатации.

Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.

Курс по DevOps
Обучение профессии Data Science
Обучение профессии Data Analyst
Курс «Python для веб-разработки»

Eще курсы

Профессия Веб-разработчик
Frontend-разработчик
Профессия Этичный хакер
C++ разработчик
Продвинутый курс «Machine Learning Pro + Deep Learning»
Курс по Machine Learning
Курс «Математика и Machine Learning для Data Science»
Разработчик игр на Unity
Курс по JavaScript
Профессия Java-разработчик
Курс по аналитике данных
Профессия iOS-разработчик с нуля
Профессия Android-разработчик с нуля

Источник: habr.com