Всем привет!
Хочу в этой статье поделиться кусочком мудрости относительно того, как настроить систему автоматического развертывания нашего приложения из BitBucket репозитория на Azure Web App, известный ранее под именем Azure Web Site. Формат данной статьи больше похож на краткое руководство, что для меня не свойственно, но многие люди задавали мне эти вопросы и я хочу ответить на них.
Для начала давайте поговорим чуток о структуре нашего репозитория. Я большой фанат веток и я считаю, что под каждую задачу у нас должна быть своя ветка в репозитории. Соответственно я хочу предложить всем и каждому использовать следующего вида структуру репозитория:
- master (он же main, default и т.д.) — тут будет лежать последняя стабильная версия нашего приложения.
- develop (он же dev, trunk и т.д.) — тут мы будем вести основную разработку.
- deploy/prod — используя эту ветку мы будем публиковать изменения на рабочее окружение.
- deploy/qa — используя эту ветку мы будем публиковать изменения на тестовое окружение.
и так далее.
Многие люди задавали мне вопрос — а зачем нам отдельно ветка master и deploy/prod, ведь они дублируют друг друга. И да и нет, я бы сказал. Эти ветки дублируют друг друга с точки зрения кода, но они несут абсолютно разный смысл. Как только у нас появляется коммит в ветке master — это признак того, что у нас готова новая стабильная версия приложения. А как только коммит заходит в ветку deploy/prod — это признак того, что мы готовы новую версию выкатить нашим пользователям. Порой бывает так, что два этих события не совпадают по времени.
Теперь идем на новый Azure портал (portal.azure.com). Сразу оговорюсь что все это можно сделать и со старого портала (manage.windowsazure.com), но на новом портале это делать намного удобнее.
На новом портале находим нужный нам сайт и выбираем пункт «Set up continuous deployment» в разделе «Deployment».
Далее выбираем все необходимые нам настройки для публикации, а именно: источник, авторизизированный пользователь, организация, репозиторий и ветка. Все эти настройки мы выбираем из удобных выпадающих списков.
Вот собственно и все. Публикация настроена и теперь нам нужно немного подождать и наш сайт уже будет опубликован на Azure Web App.
Теперь еще одна приятная новость для всех любителей mercurial. Если вы присмотритесь внимательнее к моему проекту (https://bitbucket.org/boykoant/myazureapp), то увидете, что он хостится именно в mercurial репозитории. Таким образом мы подтвердили на практике, что Azure Web App умеет публиковать проекты из mercurial репозиториев.
Отлично. Теперь у нас полностью готова публикация на продакшен окружение, но как же быть с тестовым окружением? Тут все также довольно просто. Сперва создадим новый сайт слот. Для этого пойдем в раздел «Deployment slots» внутри «Deployment».
При нажатии на кнопку «add» нам остается заполнить нехитрую форму из двух полей, а именно — имя новго окружения и копировать ли туда настройки из существующего окружения (можно оставить настройки по умолчанию).
Как только окружение будет создано мы сможем зайти и в него. Самое приятное то, что новое окружение ведет себя как полноценный сайт. Следовательно мы можем повторив прошлый шаги настроить сюда развертывание из другой ветки нашего репозитория, а именно из ветки deploy/qa.
Что мы получили на данный момент:
- 2 независимых окружения (prod и qa). Каждое из которых живет своей жизнью и не влияет на работу соседей.
- 2 независимых ссылки для тестирования нашего сайта, в моем случае это http://myazureapp-demo.azurewebsites.net/ и http://myazureapp-demo-qa.azurewebsites.net/.
- Автоматическое развертывание приложения каждый раз как мы пушим новый коммит в нужную ветку.
Возможность развертывать приложение не из Microsoft системы контроля кода, что будет особенно приятно для людей из мира Open Source. - Время потраченное на прочтение данной статьи и повторение всех действий на собственной подписке не должно было превысить 30 минут. А повторная настройка всего вышеперечисленного не должны превысить 5 минут.
И немножко философии в конце. Я показал как создавать 2 окружения — prod и qa используя одну из моих любимых возможностей Azure Web App, а именно site slot (aka deployment slot), но можно пойти и другим путем. Сам site slot доступен вам только в платной версии Azure Web App и вы не сможете провернуть такое на бесплатном тарифном плане. Но вам никто не мешает создать 2 разных Azure Web App (другими словами 2 разных сайта) и настроить один для рабочего окружения, а другой для тестового. На выходе вы получите все преимущества перечисленные мною в данном руководстве. С другой стороны, используя site slot вы получите дополнительные преимущества, но о них мы поговорим в следующей статье.
