Анализ дня: книга Continuous Delivery

    Всем привет. После краткосрочного прогула я снова на связи.
    Пару недель назад купил книгу "Непрерывное развертывание" (Continuous Delivery на английском). Времени на чтение от корки до корки так и не нашел, пока прочитал только первую главу. Чтобы все-таки отбить деньги выложенные за книгу, решил немного по-другому к ней подойти. А именно, выписать сначала конкретные вопросы, на которые хочу найти ответы. Ну а после уже читать только те части, которые могут помочь получить ответы. Вопросов смог сформулировать 2 и третий на подходе:

1. Сейчас занимаюсь настройкой CI, поэтому нужно прочитать только соответствующую главу в книге. Глядишь что и приглянется. 
2. Сохранения и развертывание конфигураций и настроек инструментов, среды, системы. В первую очередь речь идет о различных конфигах, которые после чекаута из перфорса должны быть ручками допилены под машину каждого разработчика. 

    Раньше у меня не было проектов с таким диким количеством конфигов. Конфиги клиента, сервера (у каждого разработчика свой сервер), конфиги инструментов и т.д. В результате все это либо висит на чекауте в ченджлисте с именем "don't commit", либо правится локально после снятия флаг read only. Естественно такой подход приводит к тому, что либо конфиг забывают залить когда нужно, либо наоборот заливают когда не нужно. Изысканиями и результатами поделюсь. 

    Кстати а как вы храните конфиги и работаете с ними? 

Анализ дня: задача дня, бранчи и снова бранчи

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

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

    Вторая тема более практична.
    На проекте, как и у всех, у нас есть транк (основная ветка) и бранчи, созданные по разным причинам. Один из этих бранчей называется stable. Работа строится следующим образом: две недели набиваются фичи в транк, после чего готовые вещи интегрируются в ветку stable и мы еще неделю тратим на стабилизацию данной ветки. После стабилизации собирается клиентский билд и прямо из ветки идет обновление сервера.
    Естественно скрипт обновления сервера работает по head ревизии и естественно, если кто-то во время стабилизации stable случайно дернет этот скрипт, то всем поплохеет.
    Собственно, чтобы обезопасить себя, неделю назад добавили ветку stable_candidate. Расчет прост - стабилизация билда идет в новой ветке, а потом по готовности все это интегрируется в stable. Но не все идет так как хочется. После недели терзаний и мыканий поняли, что все равно остается открытым два критичных вопроса:

1. То что стабилизировали stable_candidate, не гарантирует что stable будет рабочим после интеграции
2. Некоторые фичи и процессы просто невозможно протестировать в stable_candidate. Соответственно возвращаемся к исходной проблеме - stable ветка какое-то время все равно будет в неопределенном состоянии

    Решение пришло одновременно двоим и оно до банальности простое. Новый бранч нужно делать не до стабилизации, а после.

    Всем доброй ночи