Рубрика «release management»

Фича = задача и далее по тексту :-)

Что есть задача для разработчика?  

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

После разработки

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

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

Раньше наш процесс релиза был ручным, медленным и напичканным ошибками.
Мы проваливали спринт за спринтом, потому что не успевали сделать и выложить фичи к следующему Sprint Review. Мы ненавидели наши релизы. Часто они длились по три-четыре дня.

В этой статье мы опишем практику Stop the Line, которая помогла нам сфокусироваться на устранении проблем конвейера выкладки. Всего за три месяца нам удалось увеличить скорость деплоя в 10 раз. Сегодня наш деплой полностью автоматизирован, а релиз монолита занимает всего 4-5 часов.
Stop the line или прокачай свой pipeline, йоу - 1
Читать полностью »

#NoDeployFriday: помогает или вредит? - 1

Нужно ли запрещать деплоить в production в определённое время? Или движение #NoDeployFriday стало реликтом времён, когда не было всеобъемлющих интеграционных тестов и непрерывного деплоймента?

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

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

Хотя многие из нас используют его постоянно, не все знают, что существует большое количество сторонних (и бесплатных) сервисов и инструментов, которые тесно интегрированы с github и расширяют его функциональность.

Сегодня в выпуске:

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

Как мы уже 4 года выживаем в условиях двух релизов в день - 1

Здравствуй! Сегодня я хочу завершить цикл статей об организации тестирования (начавшийся с изучения ошибок и опыта), рассказав о том, как же все-таки Badoo выпускает два качественных серверных релиза каждый день. Кроме пятницы, когда мы релизимся только утром. Не надо релизиться в пятницу вечером.

Я пришел в Badoo чуть более четырех лет назад. Все это время наши процессы и инструменты для тестирования непрестанно развивались и совершенствовались. Для чего? Число разработчиков и тестировщиков увеличилось примерно в два раза — значит, для каждого релиза готовится больше задач. Количество активных и зарегистрированных пользователей тоже удвоилось — а значит, и цена любой нашей ошибки стала выше. Для того чтобы доставлять пользователям максимально качественный продукт, нам нужны всё более и более мощные средства контроля качества, и эта гонка не заканчивается никогда. Цель этой статьи не только продемонстрировать работающий пример, но и показать, что какими бы крутыми ни были ваши процессы контроля качества, наверняка можно сделать их еще лучше. Технические реализации некоторых инструментов вы сможете найти по ссылкам на другие статьи, о некоторых из них нам еще предстоит написать.

В Badoo существует несколько разных QA-флоу, отличие которых обосновано разными средствами разработки и целевыми платформами (но мы используем для них общие системы: JIRA, TeamCity, Git и т.д.), и я вам расскажу о процессе тестирования и деплоя наших серверных задач (а заодно и веб-сайта). Его можно условно разделить на 5 больших этапов (хотя тут, конечно, многие мои коллеги считают по-разному), каждый из которых включает в себя и ручную, и автоматизированную составляющую. Постараюсь рассказать вам по очереди о каждом из них, отдельно выделяя то, что изменялось и развивалось в последние годы.
Читать полностью »

Как мы внедряли DevOps: управление релизами в Visual Studio Team Services - 1

Всем привет! Очередной выпуск статьи из цикла «Как мы внедряли DevOps» от команды Vorlon.JS. Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом.

Содержание цикла:

В предыдущих статьях этой серии мы обсуждали использование непрерывной интеграции, которая позволяет выполнять сборку кода при каждом изменении кода в GitHub, с помощью системы сборки в Visual Studio Team Services. Кроме того, эта сборка генерирует ряд артефактов: код приложения с его зависимостями и скрипты (в папке DeploymentTools), позволяющие автоматически создать инфраструктуру (по принципу «инфраструктура-как-код») в Microsoft Azure и развернуть приложение.
Читать полностью »

В ноябре 2015 г. мы открыли доступ к версии службы Release Management для публичного тестирования в Visual Studio Team Services. Материалы этого блога помогут Вам быстро начать использовать весь комплекс возможностей RM. Документация MSDN, доступная здесь, позволит Вам глубоко разобраться в сценариях и концепциях RM.

Вы можете использовать службу RM в двух сценариях: для внедрения кода на нескольких используемых средах и для выполнения тестов при разработке продукта. В этой публикации я расскажу о втором сценарии, а именно о том, как мы (группа разработчиков службы RM корпорации Microsoft) автоматизируем тестирование с помощью RM. Уже в течение семи месяцев мы используем RM для тестирования, за что я благодарю мою коллегу Лову (Lova).

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

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

image

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

Управление релизами в Visual Studio 2013Если вы разрабатываете сложные системы, то наверняка задумывались об автоматизации шагов, связанных с релизом. Представим, что вы создаете сложный многокомпонентный веб-сайт, инфраструктура которого разделена на несколько серверов.
Весьма заманчивым является сценарий, когда ваш процесс непрерывной интеграции и создания билдов продолжается автоматическим развертыванием этого сайта. При этом соблюдаются некоторые условия и критерии, например, требуется чтобы билд который готов к развертыванию в эксплуатационной среде проходил все тесты, и утверждался ответственными людьми из команды. Неизбежно возникает ряд моментов, которые усложняют процесс сборки, приходится создавать скрипты развертывания. Если учесть еще и процесс утверждения, то становится понятно, что такая автоматизация может быть достаточно трудоемким делом. К счастью в Team Foundation Server 2013 входит ряд инструментов, которые позволят значительно упростить управление релизами.

Кстати, 6 февраля пройдет конференция ALM Summit Russia в рамках которой мы подробно расскажем о возможностях Team Foundation Server 2013 по управлению релизами, и у читателей хабрахабра есть возможность воспользоваться скидкой 50%, для этого достаточно использовать промокод alm14_VS.
Читать полностью »

Вливание legacy истории в дерево: нахождение оптимальной точки ответвленияПо долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:

  • было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
  • конкретные инсталляции делались путем:
    • в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
    • в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте

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

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


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