Новая релизная ветка (самая старшая) отбивается от мастера. Ветки для минорных релизов и хотфиксов отбиваются от ближайшей мажорной (например V21.0.1 будет отбита от V21.0). Соответственно при мердже пулл-реквеста задачи в соответствующую этой задаче релизную ветку код будет прокинут во все старшие ветки и закончится мастером. Эта политика мерджей пулл-реквестов настроена в Bitbucket.
Например делаем задачу для V21.0.1, но уже начали разработку V21.1 и V22.0. В этом случае при мердже фича-бранча в V21.0.1 Bitbucket автоматически смерджит его дальше в V21.1, V22.0 и master.
Приветствую.
Мы используем подход feature-branch, когда на каждую задачу создается по ветке. Ветки отбиваются от релизных веток (в статье был пример V10.1 и V11.0). После разработки задачи и ревью она попадает к тестировщику, которые решает, можно ли её сразу мерджить в релизную ветку или сперва следует провести изолированное тестирование (если задача потенциально опасная). В конечном итоге ветка мерджится в версионную, на которой гоняются автотесты и проводится ручное тестирование. В некоторый момент времени релизная ветка «замораживается», на ней проводится нагрузочное и регрессионное тестирование, после чего её можно деплоить.
Да, в нашей команде мы пока деплоим только в Windows окружения, но вот наши соседи деплоят .Net Core приложения в Linux, и так как они изначально строили свою систему на основе микросервисов, то сейчас они деплоят через октопус более 30 сервисов. В общем виде это выглядит как пуш пакета на сервер + bash-скрипт для его распаковки и перенастройки сервиса.
Насчет CI — да, Octopus его не имеет, это система для деплоев, не для сборки и запуска юнит/интеграционных тестов и заменить им всё не получится. У нас вместо Jenkins TeamCity, соотвественно CI часть проходит на нём, а вопросами деплоя занимается Octopus.
Из сервисов для переводов могу подсказать еще один: nitro.alconost.com/. Тексты переводят люди, цены довольно демократичные. Пользовался им когда делал локализацию для мобильного приложения, в итоге немецкие пользователи качают чуть ли не больше, чем русскоязычные.
Для автоматического изменения версий сборок есть еще подход, описанный здесь (основан на использовании build feature «AssemblyInfo patcher»).
Из преимуществ — сам изменяет номера сборок во всех AssemblyInfo.cs в солюшене, не надо править .csproj как описано в этой статье. Из недостатков — изменяет номера сборок для всех проектов в солюшене, т.е. не позволяет для разных проектов вести различное версионирование.
Их можно все сделать одинаково маленькими.
У меня есть только 2 иконки среднего размера: для звонилки, чтобы удобнее в неё попадать, и для фотоальбома, ибо красиво.
Печальная история, сам боялся однажды так попасть.
Но в данном случае это ответственность авиакомпании, а не аэропорта, если вы покупаете билет из точки А в точку Б, а не два отдельных билета разных компаний из А в Т и из Т в Б.
В общем, лучше всего мучать представителей авиакомпаний по таким вопросам.
Буквально позавчера получил посылку с дилэкстрима. Шла недели 2-3, но до этого они еще 2 недели после оплаты тупили с отправкой посылки. Очухались после того, как я написал им в саппорт. Попробуйте и вы — может они про вашу посылку тоже «забыли».
Есть хороший сайт с букинистическими книгами — alib.ru. Сейчас глянул там — 2 варианта и оба за 3000+ рублей. Дороговато, почитаю электронный вариант. Но если очень хочется…
С ним все хорошо. Просто 2.3 прошивка не OTA и мне, честно говоря, было довольно лениво обновлять телефон вручную, и ставить потом нужные приложения. Но вот, поставил, теперь радуюсь, как будто новый телефон купил)
Например делаем задачу для V21.0.1, но уже начали разработку V21.1 и V22.0. В этом случае при мердже фича-бранча в V21.0.1 Bitbucket автоматически смерджит его дальше в V21.1, V22.0 и master.
Мы используем подход feature-branch, когда на каждую задачу создается по ветке. Ветки отбиваются от релизных веток (в статье был пример V10.1 и V11.0). После разработки задачи и ревью она попадает к тестировщику, которые решает, можно ли её сразу мерджить в релизную ветку или сперва следует провести изолированное тестирование (если задача потенциально опасная). В конечном итоге ветка мерджится в версионную, на которой гоняются автотесты и проводится ручное тестирование. В некоторый момент времени релизная ветка «замораживается», на ней проводится нагрузочное и регрессионное тестирование, после чего её можно деплоить.
Насчет CI — да, Octopus его не имеет, это система для деплоев, не для сборки и запуска юнит/интеграционных тестов и заменить им всё не получится. У нас вместо Jenkins TeamCity, соотвественно CI часть проходит на нём, а вопросами деплоя занимается Octopus.
Из преимуществ — сам изменяет номера сборок во всех AssemblyInfo.cs в солюшене, не надо править .csproj как описано в этой статье. Из недостатков — изменяет номера сборок для всех проектов в солюшене, т.е. не позволяет для разных проектов вести различное версионирование.
У меня есть только 2 иконки среднего размера: для звонилки, чтобы удобнее в неё попадать, и для фотоальбома, ибо красиво.
А есть возможность собрать подобную по Windows Phone Store?
Но в данном случае это ответственность авиакомпании, а не аэропорта, если вы покупаете билет из точки А в точку Б, а не два отдельных билета разных компаний из А в Т и из Т в Б.
В общем, лучше всего мучать представителей авиакомпаний по таким вопросам.
А за стилистику текста статьи — отдельное спасибо, очень порадовало!