Да в данных ситуациях, которые рассматриваются в статьях, это верно, изменять историю не очень хорошо. Но мы ее исправляем только для ветки релиза, и только для быстрого отката задачи, при этом история все равно сохраняется (в старой ветке), так как после ребейза мы создаем новую релизную ветку.
Мы рассматриваем наш практический опыт и у нас таких конфликтов не много, и как мы написали они действительно так же решаются вручную. Но для нас это важно было автоматизировать процесс, чтобы сократить время и уменьшить количество ошибок.
7. С базой у нас все просто если нужно что то добавить мы просто заранее делаем нужный альтер, и старый код работает как работал, потом выезжает новый код начинает работать с тем что мы добавили, проверяем все ли хорошо (при этом это уже проверялось на devel окружении), дальше при надобности удаляем ненужное. Миграция — боюсь ошибиться, но нет.
8. Нет каждый будет создавать свою из мастера (декомпозиция задач смотрите выше). Можно вести разработку в одной ветке, либо при надобности смержить их. Смерженные таски отслеживаются на уровне Git и Jira и задача если зависит от другой по коду не уедет в релиз автоматически.
9. Если вы про откат фичи с багом, то нет так как слишком много этапов тестирования и много тестов, так что все баги ловятся на этапе релиза. Бывает реверт из мастера раз в полгода, но это отлавливалось в тот же день. Если вы про выпиливании работающий фичи, то она выключается как и включалась, после этого аккуратно выпиливается код.
Спасибо за вопросы
1. Не надо даже представлять, так и есть. Только вы забыли еще группу релиз инженеров. Если говорить об обновлении, то системные администраторы обновляют сервисы и происходит это в момент наименьшего трафика на сайт. Сервер обновляется два раза в день, при этом серверное API (имеется ввиду сервер-клиент) пишется так чтобы не ломались старые версии приложений(если что разработчики меня поправят) и параллельно разрабатывается клиент. Тестируем чтобы новая фича ничего не сломала, что она работает на сервере, что работает с клиентом и выкатывается на сервер. Когда выходит новая версия клиента она использует новую функциональность на сервере.
2. У нас большие фичи декомпозируются на множество мелких задач, разрабатываются и тестируются (например на тестовых пользователях) именно в такой архитектуре, притом последней уезжает таска которая включает данную большую фичу для всех пользователей. Так что это может быть совершенно разные задачи, начиная от багфиксов и заканчивая включением новой большой функциональности на продакшен.
3. Мы используем большое количество автотестов на всех этапах тестирования, и стараемся особо покрывать критичные моменты. Плюс постфактум за проектом следит отдел мониторинга у которого огромное количество различных графиков и триггеров. Ну и конечно ручное тестирование задач которые в релизе. Опционально также проверяем продакшен вручную.
4. Работают новые фичи + ничего не сломалось при выкатке= релиз удался
Если что то случилось, мы не говорим что релиз плохой, а в максимально короткие сроки либо откатываемся, либо фиксим проблемы если они не так критичны и фикс займет очень короткое количество времени.
5. Если баг то QA, сами разработчи, если фича то продукт совместно с лидами, если рефакторинг сами разработчики. Жесткой бюрократии у нас нет.
6. Я не очень понял вопрос, думаю что тестирование ответит вам гораздо лучше:) Илья?
1) Ветка от мастера для задачи — работа — Code review — тестирование
2) Ветка релиза от мастера
3) Автомерж веток готовых и протестированных задач в ветку релиза — интеграционное тестирование и staging
4) Нашли багу, откатываем смерженный коммит задачи из релиза c помощью rebase — сборка — повторная проверка на staging
5) Едем на продакшен — проверяем опционально
6) Если все хорошо — сливаем релиз в мастер
7) Все плохо(исключительный случай:)) перекидываем линк на предыдущий релиз.
Два релиза в день, по времени, автомерж тасок останавливается за 2 часа до выкладки на продакшен очередного релиза.
Работы над системой сборки и деплоя начались где-то год назад и продолжаются до сих пор.
AIDA спроектировали и сделали за пару месяцев, но она постоянно дорабатывается.
Если оценивать проектирование, разработку и инфраструктуру под ней то 5-6 человек
8. Нет каждый будет создавать свою из мастера (декомпозиция задач смотрите выше). Можно вести разработку в одной ветке, либо при надобности смержить их. Смерженные таски отслеживаются на уровне Git и Jira и задача если зависит от другой по коду не уедет в релиз автоматически.
9. Если вы про откат фичи с багом, то нет так как слишком много этапов тестирования и много тестов, так что все баги ловятся на этапе релиза. Бывает реверт из мастера раз в полгода, но это отлавливалось в тот же день. Если вы про выпиливании работающий фичи, то она выключается как и включалась, после этого аккуратно выпиливается код.
1. Не надо даже представлять, так и есть. Только вы забыли еще группу релиз инженеров. Если говорить об обновлении, то системные администраторы обновляют сервисы и происходит это в момент наименьшего трафика на сайт. Сервер обновляется два раза в день, при этом серверное API (имеется ввиду сервер-клиент) пишется так чтобы не ломались старые версии приложений(если что разработчики меня поправят) и параллельно разрабатывается клиент. Тестируем чтобы новая фича ничего не сломала, что она работает на сервере, что работает с клиентом и выкатывается на сервер. Когда выходит новая версия клиента она использует новую функциональность на сервере.
2. У нас большие фичи декомпозируются на множество мелких задач, разрабатываются и тестируются (например на тестовых пользователях) именно в такой архитектуре, притом последней уезжает таска которая включает данную большую фичу для всех пользователей. Так что это может быть совершенно разные задачи, начиная от багфиксов и заканчивая включением новой большой функциональности на продакшен.
3. Мы используем большое количество автотестов на всех этапах тестирования, и стараемся особо покрывать критичные моменты. Плюс постфактум за проектом следит отдел мониторинга у которого огромное количество различных графиков и триггеров. Ну и конечно ручное тестирование задач которые в релизе. Опционально также проверяем продакшен вручную.
4. Работают новые фичи + ничего не сломалось при выкатке= релиз удался
Если что то случилось, мы не говорим что релиз плохой, а в максимально короткие сроки либо откатываемся, либо фиксим проблемы если они не так критичны и фикс займет очень короткое количество времени.
5. Если баг то QA, сами разработчи, если фича то продукт совместно с лидами, если рефакторинг сами разработчики. Жесткой бюрократии у нас нет.
6. Я не очень понял вопрос, думаю что тестирование ответит вам гораздо лучше:) Илья?
2) Ветка релиза от мастера
3) Автомерж веток готовых и протестированных задач в ветку релиза — интеграционное тестирование и staging
4) Нашли багу, откатываем смерженный коммит задачи из релиза c помощью rebase — сборка — повторная проверка на staging
5) Едем на продакшен — проверяем опционально
6) Если все хорошо — сливаем релиз в мастер
7) Все плохо(исключительный случай:)) перекидываем линк на предыдущий релиз.
Два релиза в день, по времени, автомерж тасок останавливается за 2 часа до выкладки на продакшен очередного релиза.
Если кратко:)
Но это бывает крайне редко.
Здесь говорилось только про ветку релиза.
AIDA спроектировали и сделали за пару месяцев, но она постоянно дорабатывается.
Если оценивать проектирование, разработку и инфраструктуру под ней то 5-6 человек