En En

Добавление новых функций


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

Исправления ошибок не должны вносить новые API или нарушать работу существующих, и им не нужны флажки.

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

Исправления в средствах защиты не должны вносить новые API, но, если это необходимо, можно нарушить работу существующих API. Такие нарушения должны быть минимальными.

Исправления ошибок

Срочные исправления

Такие исправления применяются к существующей релизной ветке. Если возможно, то они вносятся в ветку master и получают пометку [BUGFIX release].

Исправления на стадии beta

Такие исправления вносятся в ветке beta. Если возможно, то они осуществляются в ветке master и получают пометку [BUGFIX beta].

Исправления в средствах защиты

Исправления в средствах защиты применяются в ветках beta и release. Если возможно, то они вносятся в ветку master и получают пометку [SECURITY].

Функции

Функции всегда должны охватываться флажками. То же касается и тестов для функций.

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

if (Ember.FEATURES.isEnabled("feature")) {
  // implementation
}

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

Коммиты

Коммиты, которые относятся к специфической функции, должны помечаться [FEATURE htmlbars]. Это позволяет в будущем быстро идентифицировать все коммиты со специфическими функциями. Функции никогда не вносят в ветки beta или release. Когда отсекается ветка beta или release, она включает все новые функции, которые будет содержать постоянно.

Если же функция попадает в beta или release, и вы делаете коммит в ветке master, который исправляет ошибку в функции, рассматривайте это как исправление ошибки, описанное выше.

ОСобенность соглашения о наименованиях

config/environment.js

Ember.FEATURES['<packageName>-<feature>'] // if package specific
Ember.FEATURES['container-factory-injections']
Ember.FEATURES['htmlbars']

Сборки

Основанная на ветке master сборка canary будет включать все функции, которые находятся под контролем условных операторов в исходнике. Это значит, что пользователи сборки canary могут включить любые функции по желанию, активировав их до создания Ember.Application.

config/environment.js

module.exports = function(environment) {
  var ENV = {
    EmberENV: {
      FEATURES: {
        htmlbars: true
      }
    },
  }
}

features.json

Корень репозитория будет содержать файл features.json, который включает список функций, что следует активировать в сборках beta и release.

Этот файл заполняется при ветвлении и может получать дополнительные функции после формирования исходной ветки. Функции могут и удаляться.

{
  "htmlbars": true
}

Процесс сборки удалит все функции, которые не включены в список, и уберет условный оператор для функций в списке.

Тестирование с Travis

Для новых запросов на включение:

  1. Travis будет тестировать на основании ветки master со всеми включенными функциями.
  2. Если коммит имеет тег [BUGFIX beta], Travis также будет выборочно подходить к нему в beta и запускать тесты на этой ветке. Если с коммитом возникают проблемы, или тесты проваливаются, то провал считается окончательным.
  3. Если коммит имеет тег [BUGFIX release], Travis будет выборочно подходить к нему в release и запускать тесты на этой ветке. Если с коммитом возникают проблемы, или тесты проваливаются, то провал считается окончательным.

Для нового коммита на ветке master:

  1. Travis будет запускать тесты, как описано выше.
  2. Если сборка проходит, Travis будет выборочно подходить к коммитам в соответствующих ветках.

Идея в том, что новые коммиты должны быть представлены как запросы на включение. Таким образом можно убедиться, что они будут приняты без проблем. А после нажатия кнопки объединения Travis примет их в соответствующих ветках.

Решение о продолжении или прекращении

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

Ветка Beta

Все функции, оставшиеся в ветке beta, проверяются на готовность. Если какие-либо функции не готовы, они удаляются из features.json.

После этого beta получает метку и переходит в release.

Ветка Master

Все функции в ветке master проверяются на готовность. Чтобы на этом уровне функция получила статус «готово», она должна быть готовой как есть, без блокировщиков. Функции не проходят, даже если они близки к готовности и над ними ведется лишь дополнительная работа в ветке beta.

Так как этот процесс происходит каждые шесть недель, для функции довольно быстро появляется еще одна возможность попасть в сборку.

После этого ветка master переходит в beta. В файл features.json добавляются новые готовые функции.

Бета-релизы

Каждую неделю мы решаем вопрос о продолжении или прекращении внесения функций, которые остались в ветке beta. Любая функция, которая остается неготовой, удаляется из features.json.

После этого бета-релиз помечается и продвигается.


Комментарии (0)

    Выделите опечатку и нажмите Ctrl + Enter, чтобы отправить сообщение об ошибке.