Continuous delivery для сложного продукта, XP Days, 06.12.2014
•
2 gostaram•526 visualizações
Мой доклад на XP Days (http://xpdays.com.ua/). посвященный частым выкладкам сложного продукта - принципы, архитектура, жизненный цикл выкладки, паттерны и антипаттерны принятия решений. При публикации slideshare прибивает анимации, поэтому вы не увидите часть слайдов в оригинальном виде :(
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Dmitriy Yefimenko
Mais de Dmitriy Yefimenko (17)
Continuous delivery для сложного продукта, XP Days, 06.12.2014
- 1. Continuous delivery сложного продукта XP Days, Киев, 6 декабря 2014г.
- 2. Будем знакомы Дмитрий “Damiano” Ефименко. Харьков, Украина. Продуктовая разработка. Платежи банковскими картами в интернет и самообслуживании. ManAnArchDevQAE Инженер. @defimenko #xpdays
- 3. Цели В нашей пишущей стране пишут даже на стене. Вот и мне пришла охота быть со всеми наравне! ©
- 4. Сложности 1. 24/7/365. 2. Чужая беда. 3. Нельзя отнять даденое. 4. Безопасность. PCI DSS. 5. Мнооооого фич (7000+ тестов). 6. Короткий жизненный цикл фичи – частые выкладки. 7. Окружение.
- 5. Причины нарушения планов? 1. То одно. 2. То другое. 3. То третье...
- 6. How do you love each other? ©
- 7. Подходы 1. Виртуализация. 2. Автоматизация. 3. Стандартизация. 4. Мульти... все (инфраструктура, нода, фича). 5. Тестирование. 6. Мониторинг. 7. Адаптивность. 8. Визуализация.
- 9. Я не хочу иметь никакого отношения к этой вашей сложной … Linux Way = MSA
- 10. … … Без останова
- 13. Где же давнокод легаси?
- 14. Принципы 1. Не трогай давнокод легаси. 2. Разделение ответственности, прав, связей. 3. Унификация интерфейсов. • API, GUI, аппаратный. 4. Концептуальные зависимости. • Модели, слои, сервисы, интерфейсы. 5. Автоматизация. • Разработка, сборка, деплоймент, тестирование.
- 15. Жизненный цикл
- 16. Жизненный цикл 1. Нулевая точка. 2. План выкладки. 3. План отката. 4. Автоматизация. 5. Репетиция. 6. Leader – spectator. 7. Переключение.
- 17. Жизненный цикл 8. Тестирование / Мониторинг. 9. Принятие решения. 10. Журналирование. 11. Работа над ошибками. 12. Поиск неоптимальностей. 13. Постановка задач на развитие. 14. Расстановка приоритетов и запуск.
- 18. Drink with me To days gone by To the life that used to be At the shrine of friendship never say die Let the wine of friendship never run dry… © Les Miserables
- 19. И что дальше? ©Василий Ложкин
- 20. Паттерны 1. Разработчики и configuration management. 2. Журналирование и логирование Бюрокаратия. 3. Зона постоянного дискомфорта. 4. Гигиена. 5. Вместе, а не вместо. 6. Целесообразность и 2-шаговость. 7. Итеративная инкрементальность.
- 21. Итеративность vs. Инкрементальность © smashingmagazine.com
- 22. Поддержка…
- 23. Если зло неизбежно, то нужно принять его, но убить всех его детей © Filth vs. Butthurt
- 24. © Леся Гусева
- 25. Спасибо за внимание! Аплодисменты? Лучи восторга? Вопросы? Комментарии? Ругательства? d.efimenko@gmail.com skype: d.efimenko
Notas do Editor
- Каковы наши цели? Поделиться подходами в организации постоянных доставок в нашей крутейшей команде, о принципах работы которой я рассказывал вчера. Кто вчера был на докладе о продуктовой команде?
- Прайм-тайм у нас постоянно. Неаккуратное обращение с чужими деньгами – чужая беда. Пример с самолетом и парковкой. Специфика бизнеса такая, что если ты не соблюдаешь инкрементальность – с пляжа. Драконовские стандарты безопасности. Зоны, изоляция, шифрование программное и аппаратное, закрытость интерфейсов и т.д. Сложные бизнес-сценарии рождают большое количество тестов. Высококонкурентный рынок, чем короче жизненный цикл фичи – тем лучше. Каждые неделю – две – мажноный билд, каждую неделю – один – два минорных и багфикс. Банки (каналы и спеки), самообслуживание (терминалы и диалекты), платежные системы. Cтатичность и непредсказуемость.
- Человеческий фактор.
- Если делать все на отвяжись (как обычно это делается), то не вы начинаете любить работу, а работа начинает любить вас.
- Капитан Очевидность. Независимость и масштабирование. Ручная работа – адское зло. Автоматизация сборок, конфигурирования, тестирования – наше все. Любой вид сред (дев, тест, зеркало, бой) собирается и тестируется автоматически. Как быть с «местечковой» автоматизацией на коленке? Лучше её не делать, это грязь. Сходные вещи нужно делать одинаково. Когнитив допускать нельзя. Выкладка должна быть переключением между экземплярами, а не обновлением кода. Должно быть разделение уровней инфраструктуры продукта (дев, тест, зеркало, бой). ВСЕ задачи надо тестировать. Работу системных администраторов и разработчиков автоматизации – тоже. Вы пишете тесты на вашу сетевую инфраструктуру, конфигурацию и автоматизацию? Вы должны мониторить свой продукт. Всячески. Лучше функционально, с единым полем тестов. Не должно быть «так сложилось» продолжительное время. Есть боль – меняй, сложно – меняйся сам. Постоянная отдача долга или технологические каникулы? Очевидности. В виде сценария, схемы потоков данных, диаграммы переходов – любым другим способом. Без визуализации вы тратите много времени зря.
- Не усложняйте свои решения.
- Переусложнение, оверинжиниринг – могучее препятствие к быстрым выкладкам. Если бы Карлин был разработчиком – он бы выразился круче. Микросервисы – это путь Линукс.
- Где тут тонкое место? Что это тянет в архитектуре?
- Вы должны исходить из целесообразности и под задачу выработать решение. Не наоборот.
- Легаси живет рядом или в каком-то из слоев (самом первом, как обычно), окруженный тестами по самое нехочу и его никто не трогает и внутрь не лезет - страшно.
- Рефакторинг и новые фичи – через переключение. Рефакторинг архитектуры – максимальное её рассыпание и разграничение прав. Рефакторинг интерфейсов – компактность и единообразность. Ищите похожие модели и сценарии и делайте повторное использование. Должно появиться отвращение к ручной работе, которая повторяется. Как часто может повторяться ручная работа до того, как она будет автоматизирована – нужно договариваться.
- Вам нужно определиться, когда вы можете начинать готовиться к выкладке. Я начинаю готовиться при кодировании. Пошаговый чеклист, разворачиваемый постепенно в сценарии. Эти сценарии потом – постановка задачи на автоматизацию и оптимизацию. «Готовься к худшему, но рассчитывай на лучшее» [c] Метрики, метрики, метрики. Устраняй человеческий фактор. Обязательно зеркало боя. Проводи репетиции. Ранняя идентификация проблем. Трудно создать зеркало? Не смешите. Единоличная работа – зло. Мониторинг действий, голосовое сопровождение, коллегиальное принятие решений. Но, должен быть ведущий. Простой должен быт 0 секунд или стремиться к этому.
- Ручных смоков не должно быть, ручного тестирования толпой «аааа, мы переключились, ну-ка навалились всей толпой - тоже». Коллегиальное решение о успешности. Как вы думаете, кто главный в этом? Все ошибки, проблемы, улучшения, запахи – ведущий выкладки записывает, рассылает и превращает в задачи, если это можно сделать сразу. Вскрытие ошибок, выработка решения по устранению последствий и по предотвращению в будущем. Анализ запахов и улучшений, исследования, прототипы. Список их п.11 может быть расширен. Каждый пункт чеклиста из п.10 и по результатам п.12 должен быть превращен в задачу или принято решение о ненужности. Капитан Очевидность.
- И главное – не забудьте отметить
- Итак, вы вышли на какой-то уровень частых релизов. Что дальше? А дальше – нужно постоянно работать, анализировать ошибки и успехи, повышать планки, коллекционировать паттерны и антипаттерны. Свести магию к работе.
- Вы верите, что системные администраторы способны написать хороший код по автоматизации развертывания? Это не их работа. Логи, уровни логирования, аудит и анализ, протоколы работы над ошибками. Завышайте планку. Есть противоречия (безопасность, удаленность, …) – штурмуйте их. Когда рынок бросит вызов – вы будете готовы. Постоянный контроль чистоты и постоянное тестирование. Многоканальность. Переключение, а не обновление. Цели, критерии их достижения. Воткнулись в проблему – решите её + позаботьтесь о неповторении.
- Друг вашего продукта – ваш враг. Эррозия в ходе итеративной разработки – естественный процесс. Главное – чтобы последующие шаги не ломали предыдущие. Грязь, которую привносит итеративность – избежать нельзя. Можно только бороться с ней на последующих этапах, не забывая про инкрементальность.
- Изолируйте разработчиков от конечных пользователей, пусть с ними общаются специальные люди, которые отфильтруют поток сознания. Но, должно быть прозрачное взаимодействие между поддержкой и разработчиками. Если получится – теплые партнерские отношения с пониманием проблем друг-друга. Изоляции между поддержкой и разработчиками быть не должно.
- Если зло неизбежно, то нужно убить всех его детей. «Грязь» – не более, чем окружение, инструмент, «добыча».
- Прежде чем налаживать continuous delivery – разберитесь с истинными причинами ваших проблем и наметьте пути решения. Гоните тараканов, пусть лучше в голове живет белочка Ши