Говорим о DevOps на понятном языке / Habr
https://habr.com/ru/company/redhatrussia/blog/465415/

Разработка java приложении с WAD и docker
https://blog.sebastian-daschner.com/entries/reloading-javaee-apps-wad

Оператор для упрощения описания RBAC
https://github.com/FairwindsOps/rbac-manager

Видеотуры по коду kubernetes
Плейлист пополняется по мере прохождения новых
https://www.youtube.com/playlist?list=PL69nYSiGNLP0gugLYzpNR1ueyUj9GjzpK

Антипаттерны в Docker'е
https://codefresh.io/containers/docker-anti-patterns/
также выпущена в виде отдельной брошюрки
https://codefresh.io/wp-content/uploads/2019/07/Docker_anti_patterns_vertical_3.pdf

#DevOpsDeflope 48! Про DevOps и бизнес с Леоном Фаером

Обсудили
- Книгу Леона "DevOps & Business"
- Что такое DevOps и зачем он бизнесу
- Как разговаривать с бизнесом
- Как трансформировать компанию
- Может ли инженер трансформировать компанию

http://amp.gs/AImt

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

Отбросим сейчас вопрос необходимости в конкретном продукте/проекте тратить время на качество и поддерживаемость кода. Будем считать, что у нас именно такой случай, когда инвестиции оправданы. Почему же положительный пример не становится заразительным и не меняет культуру команды? Дело в том, что большинство людей в первую очередь руководствуются личными интересами и целями, а не командными. А помогают им в этом принцип разбитых окон и отсутствие неизбежности наказания.

Приведу в пример оторванную от IT историю из жизни отдыхающих. Во всех отелях публикуют объявления с просьбами не занимать лежаки «на будущее» личными вещами и полотенцами. Очень хорошее и логичное правило, позволяющее обеспечить местами большее количество человек за счёт постоянной текучки. В результате, должно стать лучше всем отдыхающим. НО не конкретному человеку в конкретный момент времени. И тут начинают работать упомянутые выше принципы. Конкретный человек хочет обеспечить себе удобное место и «забивает» его с самого утра полотенцем. По принципу разбитых окон, другие отдыхающие видят такое поведение и думают: «чем я хуже?». И начинают действовать так же. А отсутствие неизбежности наказания лишь усугубляет проблему. Все начинают вести себя так, чтобы обеспечить себе личный комфорт. В итоге, большая часть лежаков в каждый момент времени не используется по назначению...

Ровно так же в разработке. Каждый стремится закрыть свою задачу побыстрее и вкладываться в «общее благо» - второстепенная цель, которая может быть принесена в жертву. И отличным оправданием становится подобное поведение у других членов команды. А отсутствие общих командных стандартов и «наказания» за их нарушение поддерживает тенденцию.

Для достижения успехов в области качества кода ключевыми элементами являются общие командные договорённости и жесткие (желательно максимально автоматизированные) проверки их соблюдения (quality gates, статический анализ, code review, внешние аудиты и т.д.). Без этих элементов все достижения будут очень хрупкими и недолговечными.

https://github.com/k8spatterns/examples
Samples из книги Kubernetes Patterns
https://k8spatterns.io/

Судя по всему, сегодня в 91-ом выпуске TGIK будет как раз освещаться kpack
ссылка https://tgik.io/notes уже ведет на новый выпуск
https://hackmd.io/zn7DzGDtR4StxFAC7cWOKA

https://www.youtube.com/watch?v=4zkRX9PSJ5k