Рубрика «процессы разработки»

Core-Архитектура Twitter от Илона Маска
Core-Архитектура Twitter от Илона Маска

В последнее время на Twitter чуть ли не из каждого утюга льется критика по поводу оверинжиниринга. Даже некоторые вполне технически подкованные люди заявляют, что Твиттер можно было бы поддерживать вообще одному - мол, "подумаешь, твиты хостить, 80% всех микросервисов ему не нужны".

Читать полностью »

В этой статья я бы хотел перечислить и обсудить некоторые общие системные поведенческие атрибуты хорошего firmware (прошивки) для микроконтроллерных проектов, которые не зависят от конкретного приложения или проекта. Некоторые атрибуты могут показаться очевидными однако в 9 из 10 российских embedded компаний нет ни одного из перечисленных атрибутов.

1. Сторожевой таймер

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

2. Загрузчик

Читать полностью »

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

Ваши процессы попахивают. Как это понять и что делать? - 1

Читать полностью »

Какие бывают проблемы роста, кроме очевидных, когда из 15 человек становится 80, а из одной команды вырастает 10? Почему разработчики начинают удаляться от пользователей и перестают чувствовать их боль? Как им не выпадать из коммуникационных процессов?

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

Это расшифровка доклада, Читать полностью »

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

В этом смысле опыт Леона Файера, которым он делился на DevOpsConf, не то чтобы прямо уникален, но помноженный на стаж и количество различных ролей, которые он за 20 лет успел на себя примерить, очень полезен. Под катом хронология событий за 90 дней и много баек, над которыми приятно посмеяться, когда они происходят с кем-то другим, но с которыми не так уж весело сталкиваться лично.

Леон очень колоритно рассказывает по-русски, поэтому если у вас есть 35-40 минут, то рекомендую смотреть видео. Текстовая версия для экономии времени ниже.

Читать полностью »

Процессы разработки глазами эксплуатации. Взгляд с другой стороны баррикад - 1

Привет! И снова на связи Алексей Приставко.

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

Слаженная работа этих служб — залог успешного запуска и ровного «полёта» создаваемого сервиса. Но, как показывает мой (и не только) опыт, практически ни один проект не обходится без конфликтов и разногласий, жертвой которых становится ни в чем не повинный сервис.

В этой статье я постараюсь ответить на следующие вопросы:

  • Как методы и процессы разработки отражаются на эксплуатации?
  • Что движет каждой стороной конфликта?
  • В чем первопричина разногласий?

Добро пожаловать под кат!
Читать полностью »

Анонс мобильного митапа: Что делать, когда приложение стало большим? - 1
Формат

Мероприятие будет проходить в формате круглого стола

О чем будем говорить

  • Чем отличается большое приложение от маленького?
  • Как меняется кодовая база и процессы?
  • Как поймать тот момент, когда надо что-то менять?

Читать полностью »

В первой части своей статьи я рассказал о том, как мы в Badoo создали первую версию системы патчей. Если коротко, то нам нужно было найти способ исправления серьёзных ошибок прямо на production, доступный всем разработчикам. Однако первая версия была не без недостатков: мы использовали своеобразный способ раскладки, который не позволял гарантировать атомарность выкладок патчей и консистентность кода.

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

Patch me if you can: как мы отлаживаемся на production. Часть 2 - 1

Изображение: источник
Читать полностью »

Привет! Меня зовут Александр Измайлов. В Badoo я возглавляю команду релиз-инженеров. Я знаю, что во многих компаниях можно присылать изменения кода специально обученному человеку, он их смотрит и добавляет куда следует (например, именно так происходит с кодом Git). А я хочу рассказать о том, как мы автоматизировали этот процесс у нас.

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

Patch me if you can: как мы отлаживаемся на production. Часть 1 - 1

Изображение: источник
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js