CD признано в качестве практики разработки корпоративного программного обеспечения, это — результат естественной эволюции устоявшихся принципов CI. Однако CD по-прежнему довольно редкое явление, возможно, из-за сложности управления и страха перед неудачными деплоями, влияющими на доступность системы.

Flagger — это оператор Kubernetes с открытым исходным кодом, цель которого — исключить запутанные взаимосвязи. Он автоматизирует продвижение canary деплоев, используя смещение трафика Istio и метрик Prometheus, чтобы анализировать поведение приложения во время управляемого роллаута.

Ниже приведено пошаговое руководство по настройке и использованию Flagger в Google Kubernetes Engine (GKE).

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.

«В любой команде из разработчиков есть тестировщики и девопс», — с таким началом любому хочется от грусти срочно повесить нос. Не поддавайтесь на провокации, не верьте слайдам от мегазвезд. В любой критической ситуации источник правды — вот этот пост.

Со всей страны собрались любители внедрить эджайл, а за ним канбан; они на кухнях обычно делятся сакральным знаньем по вечерам. Вы догадались уже, наверное, к чему до ката весь этот текст. В Яндекс.Деньгах провели «Пиэмную», где не осталось свободных мест.

Зачем быть продактом (или проджектом), секрет успеха крутых команд, о жизни бизнеса были очерки, и как разруливать местный ад — для тех, кто не был, всё-всё записано, там знаний с опытом прям гора. Включайте фоном, как в телевизоре.

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.

С ростом количества компонентов в программной системе, обычно растёт и количество людей принимающих участие в её разработке. Как следствие, для сохранения темпов разработки и простоты сопровождения, подходы к организации API должны стать предметом особого внимания.

Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.

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

Вступление

В конце марта 2018 я начала работать, как мне казалось, в надежной и симпатичной шведской компании с большим IT-отделом в 200 человек. Я мечтала участвовать много в разработке новых приложений на Java, лучше узнать фреймворки семейства Spring, учиться новым технологиям (до этого случайно угодила в компанию, где всё ещё пользовались SVN), участвовать в интересных дискуссиях, получать и оставлять адекватные комментарии в Code Review (а не заморачиваться только на пробелах и отступах) — одним словом, быть частью профессионального коммьюнити и иметь возможность развиваться как специалист. Небезызвестная шведская корпоративная культура и пестрый международный коллектив подбадривали меня и укрепляли в моих надеждах на наше с компанией плодотворное сотрудничество.

В первые месяцы я действительно могла сказать, что нашла всё то, что искала. Я быстро погрузилась в разработку, приняла участие в выпуске MVP, узнала много нового и даже выучила Kotlin, что позволило мне внести посильный вклад и в другие проекты.

Но моё счастье длилось недолго…

Этот пост вдохновлен темой в форуме Go Forum, начатой Nate Finch. Этот пост сконцентрирован на языке Go, но если пройти мимо этого, я думаю, идеи представленные тут широко применимы.

Почему нет любви?

Пакет log в Go не имеет уровней для логов, вы можете сами вручную добавить приставки DEBUG, INFO, WARN, и ERROR. Также logger тип в Go не имеет возможности включить или выключить эти уровни отдельно для выбранных пакетов. Для сравнения давайте глянем на несколько его замен от сторонних разработчиков.



glog от Google имеет уровни:

• Info
• Warning
• Error
• Fatal (завершает программу)

Посмотрим на другую библиотеку, loggo, разработанную для Juju, в ней доступны уровни:

• Trace
• Debug
• Info
• Warning
• Error
• Critical

Loggo также имеет возможность задать уровень детализации лога для нужных пакетов по отдельности.

Перед вами два примера, явно созданных под влиянием других библиотек для логирования на других языках.

Фактически их происхождение можно проследить до syslog(3), возможно, даже раньше. И я думаю, что они не правы.

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

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

Как и любое другое решение, Helm — пакетный менеджер для Kubernetes — имеет плюсы, минусы и область применения, поэтому при его использовании стоит правильно оценивать свои ожидания…


Мы используем Helm в своём арсенале инструментов непрерывного выката. На момент написания статьи в наших кластерах более тысячи приложений и примерно 4000 инсталляций этих приложений в различных вариациях. Периодически мы сталкиваемся с проблемами, но в целом довольны решением, не имеем простоев и потерь данных.

Основной мотив написания статьи — предоставить пользователю объективную оценку основных проблем Helm 2 без категорических заключений, а также желание поделиться опытом и нашими решениями.

И снова здравствуйте!

В прошлый раз мы рассказывали о выборе инструмента в Ostrovok.ru для решения задачи проксирования большого количества запросов к внешним сервисам, никого при этом не положив. Статья закончилась выбором Haproxy. Сегодня я поделюсь нюансами, с которыми мне пришлось столкнуться при использовании этого решения.

Доброго времени суток, хабровчане!

Про эту компанию знают все. Кто-то в ней даже работал или продолжает работать. Я думаю, сложно найти в РФ, да и на территории СНГ, человека который не слышал о холдинге Сбербанка. Именно холдинг, так как очень много компаний которые обслуживают Сбербанк и контролируются им же. Так вот я поработал в двух таких компаниях за один год — это Сбербанк-Технологии (далее СБТ) и Сбербанк.

Эта статья содержит краткую выжимку из моего собственного опыта и опыта моих коллег, с которыми мне днями и ночами доводилось разгребать инциденты. И многих инцидентов не возникло бы никогда, если бы всеми любимые микросервисы были написаны хотя бы немного аккуратнее.

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

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

Когда вы приезжаете в автосервис, вы пишете ТЗ? Конечно, многие из вас разбираются в автомобилях, и среди моих знакомых есть ребята, которые могут запросто разобрать и собрать обратно коробку передач. Но, все-таки, большинство из нас ставят задачу в виде «что-то стучит, когда еду быстрее 40 км/ч» или «плохо дует из дефлекторов, может кондиционер, или, не знаю, что там».

Если бы мастер в автосервисе на такой вопрос сказал что-то вроде «говорите конкретно, что надо сделать с вашей машиной», продолжили бы вы пользоваться его услугами? Думаю, что нет. Большинство из нас покупают машину не для того, чтобы в ней разбираться, и так поступают не только блондинки из анекдотов, или новые русские, которые (в тех же анекдотах) меняют автомобиль, когда заполнилась пепельница.

В работе с программистами у бизнеса выбора нет. И чем дальше, тем будет хуже. Еще не перевелись умельцы-энтузиасты, для которых решить вопрос самостоятельно – дело чести, но всеобщее разделение труда и засилье юридических-бюрократических подходов к делу быстро и надежно такой энтузиазм убивает.

Многие говорят – рассказывать надо не только об успехах, но и о неудачах. Полностью с этим согласен — понимание своих неудач, их причин и последствий, иногда ценнее любых успехов.

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

Но этот ад принес невероятную пользу мне, чем и поспешу поделиться с вами. Не буду спойлерить, а вы не бегите в конец публикации, чтобы прочитать.

Обо всем по порядку.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Многие с подозрением относятся к перспективе чего-нибудь форкнуть и дописать самостоятельно. Зачастую цена слишком высока. Особенно странно слышать о собственных JDK, которые якобы есть в каждой достаточно крупной компании. Что за чертовщина, с жиру бесятся? В этой статье будет подробный рассказ о компании, которой всё это приносит реальную коммерческую выгоду, и которая проделала чудовищную работу, ведь они:

• Разработали мультитенантную виртуальную Java-машину;
• Придумали механизм работы объектов, не приносящих оверхеда на сборку мусора;
• Сделали что-то вроде аналога ReadyNow из Azul Zing;
• Запилили собственные корутины с yield-ами и континуациями (и даже готовы поделиться опытом с Loom, о котором я писал осенью);
• Прикрутили ко всем этим чудесам собственную подсистему диагностики.

Как всегда, видео, полная текстовая расшифровка и слайды ждут вас под катом. Добро пожаловать в ад одного из самых сложных направлений адаптации открытых проектов!

Доктор, откуда вы берёте такие картинки? Уголок «обложек O'Reilly»: бэкграунд для КДПВ предоставлен Joshua Newton и изображает священный танец Сангьянг Джаран в городе Убуде, Индонезия. Это классический балийский перформанс, состоящий из огня и трансового танца. Человек с непокрытыми пятками двигается вокруг костра, разведённого на кокосовой шелухе, распихивая ногами разное и танцуя в трансовом состоянии под действием конского духа. Идеальная иллюстрация для собственного JDK, правда?

В предыдущих статьях о dapp было рассказано про сборку приложений и про запуск в Minikube. При этом dapp запускался локально на машине разработчика. Однако инструмент задумывался для поддержки процессов непрерывной интеграции (CI) и сами мы используем его в основном в связке с GitLab. Чем dapp помогает в процессах CI/CD?

В конце прошлого года на Reddit представили плагин к kubectl, помогающий производить отладку в pod'ах кластера Kubernetes — kubectl-debug. Эта идея сразу же показалась интересной и полезной нашим инженерам, так что мы решили посмотреть на её воплощение и рады поделиться своими результатами с читателями хабры.

Нам очень нравится формат AMA (ask me anything) на Reddit, когда кто-нибудь (в нашем случае – команда разработчиков) приходит в сабреддит AMA и говорит, что готов отвечать на заданные вопросы. Из самых запоминающихся сессий Ask Me Anything, например, команда инженеров Space X, или инженеры из Google, и даже действующий президент США Барак Обама четыре года назад отвечал на вопросы на Реддите. Недавно наша Android-команда проводила AMA и в онлайн-режиме отвечала на вопросы разработчиков.

Но в России нет своего Реддита. Зато есть свой Хабр. Поэтому мы решили прийти с форматом «задай нам вопрос» сюда. И не с пустыми руками, как велят правила AMA. Чтобы вам было проще понять тему, мы выбрали одну из наших команд – «Платформу» – и попросили ребят рассказать, чем они занимаются, на чём программируют и чего добились за время существования команды. И подвели небольшие итоги уходящего 2016 года. Поехали!

Оглавление

1. Чем занимается «Платформа»
2. Сервисы: Pinba, SoftMocks и другие
3. Системное программирование. Как мы начали использовать Go и к чему это привело
4. Фотографии
5. Скриптовое облако
6. LSD: Live Streaming Daemon
7. Cassandra Time Series: что это и как работает
8. Badoo AMA: задай вопрос разработчикам «Платформы»

Пруф, что это действительно мы.

В условиях highload сложность оптимизации реляционных баз данных возрастает на порядок, так как покупка ещё более мощного железа обходится дорого а также уже нет возможности просто выключить приложение ночью для долгого процесса альтера БД и миграции данных.

Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.