В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.

Тестирование длинных web-форм в различных браузерах и в разрешениях — не только крайне необходимый, но и раз уже на третий-четвертый — исключительно нудный и требующий концентрации процесс. А значит, это именно та область, которая сама просится в автоматизацию. Этим-то мы и занялись.

В этой статье на Хабр расскажем о нашем опыте тестирования больших экранов инструментами Protractor, Zalenium и Selenium-grid. Как мы поэтапно внедряли эти инструменты автоматического UI-тестирования и через какие сложности нам пришлось пройти.

На все про все достаточно 50 чашек кофе.

Помимо обозначенного выше эмпирического правила мы публикуем краткую заметку о моментах, на которые нужно обратить пристальное внимание, чтобы на бою и в процессах ничего не сломалось. Заметку составили по горячим следам релиза мобильного сервиса, совсем мигрировавшего на .Net Сore (начало было положено тут). Нам удалось выполнить эту операцию незаметно для заказчика, почти не останавливая основной процесс разработки.

Ниже будет готовый план действий, будет очень емкий тест-лист, будет вот эта картинка для настроения:

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

Для начала достаточно ответить на два простых вопроса:

• Зачем это мне?
• Что я расскажу интересного и полезного хабраобществу?

После чего можно взять план из этой статьи (или придумать свой) и сделать это.


Есть творческие этапы и технические. В этой статье поговорим о творческих. Рассмотрим:

• Зачем писать статьи,
• Откуда взять тему для статьи,
• Где найти время, чтобы её написать,
• Основные этапы работы над текстом,
• Что делать, если статья «не идёт»,
• И с чего начать, если ты ни разу не писал на Хабр.

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

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

• .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
• Kubernetes для оркестрации микросервисов,
• Docker для создания образов микросервисов,
• шина интеграции Rabbit MQ и Mass Transit,
• Elasticsearch и Kibana для логирования,
• TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.



Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.

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

Изначально основная часть модулей была заточена под веб, потому что с системами работают офисные сотрудники со стационарных компьютеров. О том, как мы проработали дизайн-систему для веба, мы писали ранее.

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

Для дизайн-проектирования это ставит нам 2 задачи:

1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.



2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.

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

Всем привет!

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

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

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

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

Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.

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

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

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.

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

Наша система отправляет 206 различных уведомлений из 35 систем девятью способами. Вот такой фронт работ. Как для этой махины мы создавали единую коммуникационную платформу — центр уведомлений — рассказываем под катом.

Мы съездили на конференцию для мобильных разработчиков Mobius и решили рассказать, что из докладов запомнилось больше всего. Сссылки ведут на презентации.

• Нам понравился доклад Vyng про профайлинг. Артур Бадретдинов сделал обзор инструментов, которые можно использовать для оптимизация отображения данных и анимации. Например, Gfxinfo показывает статистику кадров, а Hierarchy Viewer – иерархию и скорость отображения компонентов экрана. Были и другие инструменты. Идея доклада в том, что нужно всегда замерять, сколько времени что занимает, и какая у тебя иерархия. Если ты всё протоколируешь, то сможешь быстро найти ошибку. Ещё раз о пользе оптимизации UI.

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

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

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



Так появилось наше приложение для пассажиров S7 Airlines под iOS и Android, которые хотят помочь авиакомпании стать лучше. Для этого достаточно скачать приложение на смартфон и пройти все опросы, которые там появятся. Ниже расскажем подробнее, как мы определяем, кого, когда и в какой момент спрашивать.

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

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



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

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

Сегодня расскажем, как переводили на микросервисы монолитное решение. Через наше приложение круглосуточно проходит от 20 до 120 тысяч транзакций в сутки. Пользователи работают в 12 часовых поясах. В то же время функционал добавлялся много и часто, что довольно сложно делать на монолите. Вот почему системе требовались устойчивая работа в режиме 24/7, то есть HighLoad, High Availability и Fault Tolerance.

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

Проблематика

Мы делаем рабочие инструменты для корпоративных пользователей. Делаем их хорошо. Красивыми и понятными.

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

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

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

У нас уже была страница смены пароля, но механизм работы был не оптимальным. Вот как всё происходило. Пользователь оставлял заявку в домене на смену пароля. В ответ система, в свою очередь, оставляла заявку, которую администратор обрабатывал вручную. Он генерировал пароль в домене, после чего приписывал его в заявке. Пользователю приходило email-уведомление: “Ваш пароль изменён на такой”.

Нас смущали три момента:

1. Sharepoint, от которого мы уходим в тех местах, где он не нужен.
2. Потребность в участии администратора. Нам не хотелось отвлекать квалифицированного специалиста на подобные рутинные и частые операции.
3. Мы присылали пароль прямо в письме, что не очень-то безопасно. Такой пароль можно прочесть с экрана. Появляется много вариантов, как он может утечь.

И ещё был психологический момент: система создавала такие сложные пароли, что их было сложновато запомнить, оставалось только где-то записать.Тоже небезопасно. Зато такой пароль очень просто забыть. Можем предположить, что это обстоятельство тоже влияло на количество заявок на смену пароля.

Итак, стало понятно, что механику смены пароля пора изменить.

Мы продолжаем рассказывать про миграцию мобильного сервиса в ASP.NET Core и Docker. В этой статье будет идти речь про модуль WCF-клиента, упомянутый в предыдущей статье, NTLM-авторизацию и другие проблемы при его миграции. Сейчас расскажем, почему нам пришлось немного изучить анатомию и пощупать .NET Core изнутри.

Мы продолжаем наш путь к Continuous Delivery (CD) и High Availability (HA), основанной на избыточности. В предыдущей серии мы перевели API для мобильного приложения на .NET Core. Следующий логичный шаг для достижения CD — настроить сборку в Docker-контейнер.

Сегодня поделимся нашим getting-started гайдом по настройке сборки docker-образов и деплоя в Kubernetes в TFS для разработчиков .NET.

(Предполагается, что к этому моменту вы уже мигрировали ваше ASP.NET приложение на ASP.NET Core, а если нет, читайте нашу прошлую статью).

За мной, за мной, читатель, и я проведу тебя в чарующий мир автоматизации разворачивания окружения на серверах под управлением Linux семейства RHEL.

Один из наших java-проектов вырос, стал совсем взрослым и сейчас занимает 4 контура:

Dev — контур для команды разработки,
Qa — контур для команды тестирования,
Stage — контур для демонстрации новых фич заказчику,
Production — боевой контур.

Каждый контур содержит два одинаковых сервера с идентичным набором компонентов окружения для нашего приложения:

linux Oracle — операционная система,
jdk — комплект приложений Java,
haproxy — proxy сервер,
nginx — веб-сервер для отдачи статики,
mysql — субд.

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

После краткого сравнения систем управления конфигурациями был выбран Ansible. В его пользу сыграли простота, гибкость и отсутствие агентов на управляемых серверах.