Pull to refresh
4
0
Александр @ADSapozhnikov

DevOps

Send message

Собираем свой flow для git с нуля

Reading time 6 min
Views 17K

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).


Ее основными тезисами были:


  • GitFlow противоречит тезису "ветки должны быть короткоживущими".
    Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
  • GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
    Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
  • GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
  • GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
  • Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.


    Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.



Так что делать-то?

Читать дальше →
Total votes 23: ↑21 and ↓2 +19
Comments 48

«Восстание машин» часть 1: continuous delivery для базовых Docker образов

Reading time 9 min
Views 9.1K


Всем привет! Меня зовут Леонид Талалаев, я работаю в Одноклассниках в команде Платформы. Более 3-х лет назад мы запустили внутреннее облако one-cloud. Сейчас под его управлением находятся тысячи серверов в 4 дата-центрах, сотни сервисов и более десятка тысяч контейнеров.


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


В серии статей «Восстание машин» я расскажу, как автоматизация в one-cloud помогает экономить не только время, но и деньги. Сегодня пойдет речь о том, как мы реализовали процесс непрерывной доставки изменений базовых Docker образов.

Читать дальше →
Total votes 32: ↑31 and ↓1 +30
Comments 26

CI/CD в Playrix: как мы собираем и тестируем наши игры

Reading time 11 min
Views 12K
Команда должна фокусироваться на создании прекрасных и успешных игр, для всего остального есть CI.

Где мы применяем CI? Какие подходы и концепции используем? Зачем собирать и тестировать билды? Развернутый рассказ о CI и о том, как он устроен в Playrix, потянет на курс лекций. Под катом — краткая выжимка и немного акцентов.

Читать дальше →
Total votes 53: ↑49 and ↓4 +45
Comments 3

Свой CI/CD для Unity

Reading time 5 min
Views 9.2K
image

Сейчас я расскажу, как выглядит процесс разработки на Unity в маленькой gamedev компании и как мы его улучшаем и автоматизируем. Всё-таки 2020 год на дворе, хватит уже мышкой водить…
Читать дальше →
Total votes 7: ↑7 and ↓0 +7
Comments 5

DevOps — хорошо, но что делать? Как сократить ручной труд и прийти к желаемому результату

Reading time 15 min
Views 2.7K
Итак. В 2018 году на Heisenbug (Московская конференция по тестированию) Барух Садогурский (Developer Advocate в компании JFrog) презентовал интересный кейноут, в котором рассказал о своих основных идеях того, «куда надо идти». В 2019 году на том же  Heisenbug состоялся сиквел его доклада про то, КАК идти, чтобы достичь этой цели. С одной стороны, мне бы хотелось поддержать версию движения Б. Садогурского, которую он транслировал, но во первых мне она еще не известна, а во вторых рискну сформулировать свое видение и описать свой личный путь, основываясь на своем опыте.
Читать дальше →
Total votes 11: ↑11 and ↓0 +11
Comments 8

Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии

Reading time 21 min
Views 67K
Прим. перев.: service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов» или «сервисная сетка», а чуть позже некоторые коллеги стали продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.


Комикс от Sebastian Caceres

Введение


Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.

Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.

В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по сервисным сеткам. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.
Читать дальше →
Total votes 47: ↑46 and ↓1 +45
Comments 12

Расшифровка вебинара «SRE — хайп или будущее?»

Reading time 19 min
Views 8.1K

У вебинара плохой звук, поэтому мы сделали расшифровку.


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

Total votes 14: ↑13 and ↓1 +12
Comments 2

Дж. Х. Рейнвотер «Как пасти котов»: по ту сторону разработки

Reading time 9 min
Views 2.6K


Продолжаем делиться выжимками из руководства для тех, кто готовится возглавить группу разработки. В предыдущей части мы говорили обо всем чужеродном, что подстерегает технического лидера на новой должности, теперь же возвращаемся к вещам родным и знакомым – собственно программированию. Здесь вчерашний разработчик может чувствовать себя в своей стихии, но расслабляться ему не приходится – зона ответственности растет и сдвигается. Под катом представляем краткий обзор всех новых обязанностей и советы по адаптации, которые приводит в своей книге Рейнвотер.
Читать дальше →
Total votes 5: ↑5 and ↓0 +5
Comments 0

Мечтают ли YML программисты о тестировании ansible?

Reading time 4 min
Views 4.4K

kitchen-ci schema


Это текстовая версия выступления 2018-04-25 на Saint-Petersburg Linux User Group. Пример кода тут: https://github.com/ultral/ansible-role-testing


Полагаю что вы используете configuration mangement, а не bash. Т.е. ваша конфигурация это код. Если мы говорим, что инфраструктура это код, то к её созданию должна применяться та же философия, что и для разработки ПО. Вы задумывались об этом? Как у вас это сделано? А у других?

Читать дальше →
Total votes 10: ↑7 and ↓3 +4
Comments 15

JSON API – работаем по спецификации

Reading time 23 min
Views 158K
В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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


Total votes 71: ↑68 and ↓3 +65
Comments 110

Автоматическая сборка iOS-приложений на разных версиях Xcode с помощью Jenkins

Reading time 6 min
Views 28K
Если к вам уже приходили с вопросом «Где можно получить свежую сборку?», то вы прекрасно понимаете, зачем нужна автоматизация сборки и распространения. Никто не хочет тратить лишнее время на рутинную работу. Раньше мы пользовались утилитой под названием iOSBetaBuilder (http://www.hanchorllc.com/betabuilder-for-ios/). Это приложение предназначено для упрощения распространения AdHoc сборок iOS-приложения: нужно только ввести название и версию проекта, адрес (URL), где хочется выложить сборку, и получаются сгенерированные index.html и manifest.plist. На первое время этого достаточно.

Но когда проект достигает стадии багфиксинга, тратить лишние 5 минут на сборку и перепубликацию для QA – неохота и некогда. А когда проектов становится много, а их сборки становятся дольше… В рамках компании затраты времени помноженные на количество проектов становятся слишком существенными, и приходит время автоматизации.

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

Для тех, кто уже в теме, есть интересный раздел в конце статьи: как настроить сборки с различными версиями Xcode на одной машине.

Читать дальше →
Total votes 20: ↑18 and ↓2 +16
Comments 17

Автоматическая сборка Unity-проектов для Android и iOS с помощью Gitlab CI

Reading time 14 min
Views 13K

В этой статье хочу рассказать о подходе к сборке Unity-проектов на android и ios через Gitlab на собственных сборщиках с macOS.


Я работаю в небольшой gamedev компании, и задача автоматизации сборки появилась из-за следующих проблем:


  • 5 распределенных команд должны собирать проекты из любой точки мира
  • должны поддерживаться разные версии юнити
  • сборщик должен обеспечивать как минимум 5 сборок в неделю от каждой команды
  • сертификаты должны храниться централизованно, а не у разработчиков
  • собранные билды должны быть доступны по ссылке в любой точке мира
  • проекты должны проверяться на наличие обязательных библиотек (рекламные sdk и коды, локализация, сохранения)
  • конфигурирование сборки для команд должно производиться в одном месте
Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Comments 4

Как за день поднять CI для iOS-разработчиков

Reading time 9 min
Views 27K
Cборка проекта требует от разработчика кучи утомительных операций. Когда менеджеру нужно отчитаться перед заказчиком о ходе работы, разработчик тратит время на выкачивание репозитория, подтягивание библиотек, установку сертификатов, сборку, проверку, выкладывание сборки на сервер и прочие промежуточные этапы. Но на Земле становится всё меньше рутинных действий, которые не подверглись бы автоматизации. Прогрессивная часть девелоперской среды практикует методику непрерывной интеграции (CI), и iOS-отдел компании Лайв Тайпинг решил к ней примкнуть, развернув сервер для сборок на платформе Jenkins. С тех пор началась совсем другая жизнь.
Читать дальше →
Total votes 13: ↑9 and ↓4 +5
Comments 7

Linux машина в домене Windows AD с помощью sssd и krb5

Reading time 3 min
Views 100K
Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.

Для примера будем использовать:

Домен = contoso.com
Контроллер домена = dc.contoso.com
Читать дальше →
Total votes 29: ↑28 and ↓1 +27
Comments 32

[в закладки] Шпаргалка системного администратора по сетевым инструментам Linux

Reading time 7 min
Views 82K
В повседневные задачи системных администраторов входит работа с сетями и с подключённым к ним оборудованием. Нередко роль рабочего места администратора играет компьютер, на котором установлен какой-нибудь дистрибутив Linux. Утилиты и команды Linux, о которых пойдёт речь в материале, перевод которого мы публикуем сегодня, включают в себя список инструментов различной сложности — от простых, до продвинутых, которые предназначены для решения широкого спектра задач по управлению сетями и по диагностике сетевых неполадок.



В некоторых из рассматриваемых здесь примеров вы столкнётесь с сокращением <fqdn> (fully qualified domain name, полное доменное имя). Встретив его, замените его, в зависимости от обстоятельств, на адрес интересующего вас сайта или сервера, например, на нечто вроде server-name.company.com.
Читать дальше →
Total votes 47: ↑30 and ↓17 +13
Comments 57

Kubernetes NodePort vs LoadBalancer vs Ingress? Когда и что использовать?

Reading time 4 min
Views 67K


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


Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Я не углубляюсь в технические детали. Если хотите подробностей, обратитесь к официальной документации.

Читать дальше →
Total votes 9: ↑9 and ↓0 +9
Comments 7

Moby/Docker в продакшене. История провала

Reading time 18 min
Views 73K

Обновление: у этой статьи появилось продолжение, переведённое @achekalin. В каком порядке читать — на ваше усмотрение: в этой статье можно получить удовольствие от обширной попоболи автора, а в продолжении — от сделанных им выводов.


Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.


В первый раз я встретился с Докером в начале 2015. Мы экспериментировали с ним, чтобы понять, для чего бы его можно употребить. В то время нельзя было запустить контейнер в фоне, не было команд чтобы посмотреть что запущено, зайти под дебагом или SSH внутрь контейнера. Эксперимент оказался быстрым, Докер был признан бесполезным и более похожим на альфу или прототип, чем на релиз.


Промотаем нашу историю до 2016. Новая работа, новая компания, и хайп вокруг докера поднялся безумный. Разработчики уже выкатили докер в продакшен, так что сбежать с него не удастся. Хорошая новость в том, что команда run наконец-то заработала, мы можем запускать и останавливать контейнеры. Оно шевелится!


У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).


Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.

Читать дальше →
Total votes 141: ↑132 and ↓9 +123
Comments 175

Насколько хорошо ты знаешь bash?

Reading time 4 min
Views 38K

Пользуешься командным интерпретатором каждый день? Готов решить несколько логических задачек и узнать что-то новое? Добро пожаловать под кат.
Читать дальше →
Total votes 37: ↑36 and ↓1 +35
Comments 31

Docker в продакшене: обновление

Reading time 13 min
Views 32K

Уточнение от переводчика: пост, перевод которого вы видите перед собой, был написан 23 февраля 2017 года, по мотивам исходного поста Moby/Docker в продакшене. История провала, перевод которого (за авторством olegchir) здесь, на Хабре, вызвал живые обсуждения. Просьба читать, делая поправку на дату написания — оригинальный текст написан почти год назад!


Относиться к тексту можно по-разному. Попробуйте, наслаждаясь утренним кофе, посмотреть на себя через призму восприятия автора, и подумайте, как бы он, с его опытом и отношением к работе, отреагировал, услышав тот или иной совет по поводу Docker?


Предыдущая статья Moby/Docker в продакшене. История провала оказалась хитом. Сегодня, после долгих обсуждений, сотен отзывов, тысяч комментариев, встреч с различными людьми, с крупными игроками, ещё большего количества экспериментов и большего числа сбоев, пришло время опубликовать обновления картины.


Мы рассмотрим уроки, извлеченные из всех последних общений и статей, но, для начала — уточнение, напоминание и немного контекста.


Отказ от ответственности: предполагаемая аудитория


Большое количество комментарием показло, что мир делится на людей всего 10 типов:


1) Любители


Обычно поддерживают тестовые или хобби-проекты, где нет реальных пользоваталей. Могут полагать, что использование бета-версии Ubuntu — нормально, и называют все “стабильное” устаревшим.


Я не всегда делаю рабочий код, но когда я это делаю, он работает на моей машине
Нельзя его винить: на его-то машине код работает.

какой второй тип?
Total votes 21: ↑18 and ↓3 +15
Comments 30

Работа с массивами в bash

Reading time 8 min
Views 102K
Программисты регулярно пользуются bash для решения множества задач, сопутствующих разработке ПО. При этом bash-массивы нередко считаются одной из самых непонятных возможностей этой командной оболочки (вероятно, массивы уступают в этом плане лишь регулярным выражениям). Автор материала, перевод которого мы сегодня публикуем, приглашает всех желающих в удивительный мир bash-массивов, которые, если привыкнуть к их необычному синтаксису, могут принести немало пользы.

image
Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Comments 5

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity