Когда наша команда приступила к созданию расширения Atlassian для VS Code, наша миссия была простой: создать MVP, чтобы проверить, улучшит ли использование функций Bitbucket Cloud и Jira Software Cloud внутри VS Code опыт разработчика.

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

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

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

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

Итерация в темноте

Особенность бункеров в том, что они обычно темные внутри.

Когда мы впервые начали создавать наше расширение VS Code для пользователей Bitbucket и Jira, мы работали в очень знакомом стиле, когда каждый из нас заходил в свои «пещеры кодирования» на длительные периоды времени и время от времени выходил на воздух, чтобы проверить канал Slack, который мы настроили.

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

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

Чтобы пролить свет (каламбур) на некоторые из проблем:

  • Никто не любит часами сидеть в комнате с доской Jira на экране, пока кто-то лихорадочно набирает текст, пытаясь ввести проблемы Jira, в то время как ведутся горячие дискуссии.
  • Как только кодирование начинается, разработчики, как правило, берутся за задачи только в пределах своих удобных знаний предметной области (разрозненных), и кросс-функциональное обучение теряется.
  • Отсутствие знаний о кросс-функциональной кодовой базе означает, что ошибки и идеи о других частях кодовой базы оставлены на усмотрение разработчика, который работает над ней, не имея возможности совместной работы.
  • Разработчики ненавидят переключение контекста, что, в свою очередь, означает:
  • ошибки или функции могут быть обнаружены, но новые проблемы Jira для них не вводятся
  • запросы на вытягивание отправляются, но для того, чтобы они были рассмотрены, должно произойти ворчание
  • комментарии могут быть введены в запросе на вытягивание, но ответы либо не отслеживаются, либо на получение новых ответов уходит несколько дней.
  • обновление задач Jira, чтобы отразить состояние проекта, - это рутинная работа, которая происходит из-за ворчания, в результате чего Jira остается в состоянии лжи.
  • Обеспечение того, чтобы единицы работы Jira были связаны с кодом в каждой ветке, и каждая фиксация в лучшем случае непоследовательна и не происходит в худших случаях.
  • Сотрудничать меньше, когда разработчики чувствуют себя экспертами

Из пещер

Однажды это случилось. Мы, наконец, достигли точки, в которой мы могли пройти аутентификацию как в Jira, так и в Bitbucket, и у нас были необходимые функции, чтобы начать поиск нашего расширения. Первый разработчик торжествующе воскликнул: «Эй, я только что одобрил этот пиар с нашим расширением!» и мы знали, что осуществимость больше не была нашей миссией ...

Появилась новая дорожная карта, почти полностью возглавляемая инженерами с небольшим надзором и большим количеством догадок: мы будем использовать эгоистичный подход и сосредоточиться на облегчении нашей собственной жизни внутри VS Code, зная, что если мы получим опыт Jira и Bitbucket (в основном ) Правильно, мы оказали бы положительное влияние на другие команды разработчиков за пределами Atlassian. Если у нас есть болевые точки в нашем цикле разработки, скорее всего, и другие команды тоже.

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

Общая пещера с действительно красивым освещением

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

Единицы работы Jira: никогда не теряйте из виду открытия

Хорошо, допустим, я разработчик ... и я работаю над кодом, когда замечаю кучу комментариев, заваленных ключами задач Jira. (мы скоро выясним, почему это происходит). Немного неприятно видеть ключи и небольшой комментарий, но не иметь доступа к деталям проблемы. Еще более неприятно выскочить из моей IDE, чтобы вставить ключ в веб-интерфейс Jira, чтобы увидеть детали, поэтому я добавляю небольшой комментарий TODO:

// TODO: add a "quick view" when hovering over Jira issue keys

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

Используя ссылку кода «Создать проблему Jira», которая появляется для настраиваемых префиксов комментариев (TODO, BUG, ​​FIME, ISSUE и т. Д.), Я могу просто щелкнуть ссылку, создать проблему и двигаться вместе с моим кодированием.

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

// TODO: VSCODE-12324 - add a "quick view" when hovering over Jira issue keys

Превращение идей в код: начало работы

Допустим, в команде есть еще один разработчик, который только что выполнил задачу и ищет, чем заняться. Она видит проблему Jira, которую мы создали выше, в своем дереве задач Jira в VS Code и открывает ее. Прочитав детали, она решает, что хочет поработать над этим.

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

  • Создайте ветку, убедившись, что ключ задачи Jira находится в имени ветки
  • Свяжите локальную ветку с новой веткой восходящего потока на Bitbucket
  • Назначьте проблему на себя
  • Переведите проблему в состояние «Выполняется», чтобы другие разработчики и «люди проекта» знали, что находится в стадии разработки.
  • Наконец, проверьте местную ветку и начните кодирование

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

Используя кнопку «Начать работу над проблемой» на экране сведений о Jira в VS Code, все это можно сделать за один шаг.

Совет: убедитесь, что все коммиты содержат ключ проблемы

Так что насчет включения ключей задач в названия веток?

Идея проста: если вы свяжете свой экземпляр Jira в настройках репозитория Bitbucket, Bitbucket будет искать ключи проблем в именах ваших веток и коммитах / комментариях PR и, среди прочего, сможет связать их в пользовательском интерфейсе Bitbucket.

Помимо пользовательского интерфейса Bitbucket, расширение Atlassian для VS Code проверяет те же самые места на предмет ключей и «волшебным образом» предоставляет вам списки проблем, связанных с вашими PR в различных пользовательских интерфейсах. Теперь вы можете легко получить более четкое представление о взаимосвязи проблемы и кода прямо в VS Code.

Итак, как обеспечить, чтобы каждый коммит содержал в комментарии ключ проблемы Jira?

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

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

Вы можете взять этот отличный скрипт и инструкции из нашего Bitbucket Snippet.

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

  • Ее товарищи по команде проведут проверку кода, чтобы уловить все, что она могла пропустить.
  • У ее товарищей по команде будет возможность опробовать новую функцию.
  • Вся команда может обсудить подход и внести любые изменения по мере необходимости.
  • У команды есть шанс «подписать» пулреквест, утвердив его.
  • Наконец, запрос на перенос можно объединить

Давайте рассмотрим это шаг за шагом, сначала создав запрос на вытягивание.

Создание запроса на вытягивание традиционно означало выход из среды IDE, навигацию по пользовательскому интерфейсу Bitbucket и создание запроса на вытягивание. С нашим расширением это теперь можно делать прямо в VS Code.

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

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

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

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

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

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

После того, как каждый товарищ по команде завершит рассмотрение запроса на перенос, он может просто нажать кнопку одобрения на экране сведений в VS Code и вернуться к своему кодированию. Точно так же наш разработчик, отправивший PR, может просто объединиться прямо с экрана деталей.

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

Управление версиями - это результат, а не план

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

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

Если раньше мы выпускали релиз в какой-то запланированный период времени, то теперь мы делаем гораздо больше релизов по мере того, как полезные функции завершены. Мы не ждем, чтобы выпустить что-либо, потому что «1.x должен быть выпущен в конце месяца». Фактически, у нас есть только одна версия, над которой мы работаем, и ее лейбл - vNext. В любой момент мы можем сказать: «пора». а через несколько минут мы выпускаем снимок и назначаем ему соответствующий ярлык.

Когда нет крайнего срока, вы никогда не закончите

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

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

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

Установите расширение сегодня и поделитесь с нами своим мнением!

Написано Джонатаном Докловичем: Джонатан работает в Atlassian почти десять лет и в настоящее время является главным разработчиком в группе интеграции продуктов. Он работал над многими продуктами Atlassian, а также над системой основных плагинов и Atlassian Connect.

Первоначально опубликовано на https://bitbucket.org 15 мая 2019 г.