Тёмный

Continuous Integration - быстро чиним разработку 

Московский клуб программистов
Просмотров 249
50% 1

Слайды и ссылки: prog.msk.ru/20...
Стоимость компьютерных экспериментов всегда была непомерно высока. Вы помните все эти фото из книг об истории компьютеров - огромные залы, бобины размером с колесо автомобиля, люди в белых халатах.
Вычислительные машины стоили дорого, так что купить их могли только крупные компании и крупные университеты.
Каждый эксперимент на таком компьютере был непозволительной роскошью. Семь раз отмерь - один отрежь: прежде, чем отправить программу на выполнение, её нужно было тщательно спроектировать и практически даже отладить. Вручную.
Ситуация стала меняться с появлением персональных компьютеров. Но не сразу. Персональные компьютеры были слишком слабы для развитых языков программирования. Smalltalk, хорошо зарекомендовавший себя на рабочих станциях Xerox, не влезал в маломощный IBM PC.
Даже достаточно железному C++ пришлось десять лет дожидаться, пока персональные компьютеры обретут достаточную мощность. Программисты писали на языке Ассемблера, C и Pascal. Экспериментировать на персональном компьютере было не так дорого, как на большом или среднем, но вы попробуйте поэкспериментировать на языке не очень высокого уровня! Замучаешься переписывать.
Всё это время планирование было нашим лучшим другом. А потом ситуация изменилась.
На рубеже XX и XXI веков программисты осознали, что эксперименты стали стоить совсем недорого. Не бесплатно, но и не так, как тридцать и даже десять лет назад.
Нашими друзьями стали наши инструменты. Системы контроля версий позволяли нам спокойно откатываться к стабильной версии когда. Интегрированные среды облегчили написание и отладку. Мы смогли отказаться от далеко идущих планов и сконцентрировались на ближайшей работе.
Позже всё это назвали гибкой разработкой программ. Одной из важнейших практик, пришедших к нам из экстремального программирования (eXtremal Programming - XP) стала непрерывная интеграция кода. Программисты в небольших командах отказались от длительной работы на отшибе. Вместо этого они стали сливать код как можно чаще, чтобы выявлять проблемы сливания как можно раньше.
Но практика применения Continuous Integration оказалась гораздо шире, чем это виделось основоположникам XP. Оказалось, что на этапе интеграции удобно проводить и дополнительный анализ кода, и выполнять специальные - интеграционные - тесты. И мы на нашем заседании поговорили об ещё одной точке зрения на CI, точке зрения системного мышления.
Рассказал нам об этом Всеволод Нечаев, Java-программист. Он долго пытался разобраться, почему CI выглядит так, как выглядит, а потом неожиданно разобрался. Ему помогла практика системного мышления, про которую мы тоже поговорили.

Опубликовано:

 

28 сен 2024

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 1   
@danikpro
@danikpro 2 года назад
Пока не досмотрел, может быть к этому пришли, так что если что игнорьте) Если читать DORA репорт, то компании молодцы в день около 3000 коммитов делают. Тут плюс не только в том что атомарность изменений вносится, но икачество кода повышается, прогнозируемость, лёгкость тестировании, отказоустойчивость растет и т.д. Суть не в том чтобы в день два минимум изменения вносить создавая работу, а чтобы минимально рабочее изменение кода коммитилось.
Далее
Watermelon magic box! #shorts by Leisi Crazy
00:20
КАК УСТРОЕН TCP/IP?
31:32
Просмотров 120 тыс.
Файлы - это сложно
1:28:51
Просмотров 425
Движение вперёд: язык Go
2:16:06
Ядерка-как это будет.
25:55
Просмотров 185 тыс.