Философия и внедрение Continuous Integration, Continuous Delivery и Continuous Deployment. Альтернативный подход разработки программных продуктов.
- 00:00:47 Цели и задачи, классический подход
- 00:01:34 Философия Continuous
- 00:02:39 Continuous Integration
- 00:09:57 Continuous Delivery
- 00:15:40 Trunk Based Development и Feature Toggle
- 00:22:20 Continuous Deployment
- 00:25:55 Подведение итогов
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
👍
Спасибо!
Но все равно, в этих системах кое чего не хватает, например нет возможности узнать, кто что меняет в данный момент, нужно договариваться с людьми, а это всегда ведет к проблемам. Вот если бы было сделано так, что если что то меняешь, то эти файлы остальным доступны только для чтения в идеале, ну или как то было видно в ветке, что по этим файлам кто то работает или собирается.
"Вот если бы было сделано так, что если что то меняешь, то эти файлы остальным доступны только для чтения..." - именно так работает некогда популярная система контроля версий SVN.
Но с появлением Git, система SVN постепенно потеряла свою популярность. Оказалось, что ситуация при которой "если что-то меняешь, остальным доступ к этим файлам только на чтение" как раз таки очень не удобная!
Гораздо удобнее иметь возможность одновременной работы над файлами, в том числе в offline и в асинхронном режиме.
С Git как раз удобно менять разные части одного файла. Кто-то, например, в шаблоне меняет шапку сайта, а кто-то в это время у себя меняет подвал, и при слиянии это безболезненно складывается. Или когда меняют разные части конфигурационного файла. Если кто-то заблокирует конфиг на неделю, то будет неудобо.
Я разрабатывал фичу месяц в отдельной ветке. Каждый день мерджил к себе мастер, перед тем как продолжить. Много раз переделывал архитектуру, менял названия классов, перемещал их. Все эти процессы были в моей ветке.
Если б все это происходило в мастере и другие программисты завязывались на моих экспериментах - было бы много правок не только у меня, а и у остальных программистов.
Поэтому - я сторонник каждую фичу разрабатывать и завершать в отдельной ветке и периодически синхрить с мастером.
Чтобы в мастер попадали уже готовые решения.
Например, заказчик еще не решил - хочет ли он зеленую, или синию, или красную кнопку. Я заведу три ветки - переключусь между ними и покажу ему результат.
Он выберет нужную - ее я и солью в мастер, остальные удалю.
Ну да, а то получится, что фича оказалась не нужна, а там уже куча кода поверх нее образовалась и как потом ее выпилить без последствий непонятно, если я за эту фичу отвечаю, та я и должен следить за изменениями в основной ветке, быстрый коммит оправдан, если ещё кто то ждёт это изменение или там просто косметические правки, которые не затрагивают важный функционал.
Согласен. Также делаю.
Подход зависит от выбранного ритма работы и коммуникации с заказчиком.
Если сроки не ограничены, заказчик не знает изначально что делает, может отменять фичи в процессе и выбирает цвет кнопки наугад уже после разработки, а не прототипирует и обсуждает фичи с разработчиками заранее, то есть смысл заводить три ветки для кнопок и отдельно их показывать заказчику через месяц, чтобы он их либо принял, либо передумал. А потом уже мержить.
Если же разработка разбита на одно- или двухнедельные SCRUM-спринты с точным набором фич, обсуждение задач и прототипирование производится до программирования, цвета выбираются по аналитике, а не наугад, то ситуация немного другая. Тогда вместо трёх веток для трёх цветов имеет смысл спрограммировать в одной ветке одну кнопку с переключением цвета и сразу задеплоить с рандомным переключением этого параметра. И потом уже поставить задачу на следующий спринт через полмесяца оставить лучший цвет по собранной статистике, а не наугад.
Если никто не торопит и чётких целей и планов нет, то фичи можно делать хоть месяцами. Но если длительность каждого этапа работ составляет одну-две недели и ожидаемые фичи и предполагаемые результаты заранее расписаны, то разработка чего-то целый месяц в локальной ветке с таким темпом не совместима. И непонятно, что делать с такой недоделанной и невлитой фичей в следующем спринте.
В этом и смысл. Если разработка классическая, то можно делать всё как угодно хоть месяцами, проверяя всё вручную. Если же это Agile, предполагающий почти ежедневную разработку фич, то там как раз удобны практики экстремального программирования: регулярный обмен кодом, постоянное тестирование работоспособности проекта, регулярный автоделой и т.п. Чтобы точно было понятно, на сколько процентов реально сделана каждая фича на прошлой неделе и чтобы можно было точнее ставить задачи на следующий спринт.
Кнопки - это абстрактный пример (продолжая его по видео).
Я о практической стороне и пишу. Зачастую бывает так (по собственному опыту), что разрабатываешь одну фичу, тут экстренно возникла новая задача, фичу нужно отложить - начать новую. Работая над второй, директор просит поправить то, что ты делал месяц назад, чтоб по быстрому сформировать некий отчет. Пока решал правки, оказывается - в изначальной фиче появились некие доп условия (меняют либу, чистят код)...
А еще может, не доделав первую фичу - вдруг ушел на больничный...
А после выхода - в такой череде коммитов пойди разбери, на чем ты там остановился...
В общем - каждой команде удобнее выбирать тот режим, который обеспечивает наиболее эфективную разработку.
Спасибо.
у всех ошибка плеера, Превышено время ожидания ответа от сайта player.vimeo.com. раньше вроде работал
у меня работает
Спасибо за серию!
Спасибо за материал, отличное объяснение без воды
Или войти через: