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

• метрик вашего продукта,
• Agile-метрик по работе команд,
• графика роста численности вашей команды,
• списка ближайших дней рождений,
• и т. д.

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

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

ГитЛаб выпускает релизы 22 числа каждого месяца.
Перевод поста про релиз 8.11 в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.

---

В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.

Начиная с версии 8.4 в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.

Bitbucket Server (ранее известный как Stash) — решение для централизованного управления разработкой, позволяющее управлять вашими репозиториями, в том числе не открывая доступа к ним извне организации. Bitbucket позволяет упростить хранение репозиториев с исходными кодами на вашем сервере и обеспечивает простоту доступа к репозиториям для всех членов вашей команды.

В мире IT известно, что Bitbucket может быть проинтегрирован с другими продуктами и платформами в единую экосистему, которая делает процесс разработки всеобъемлющим и удобным. Чаще всего Bitbucket интегрируется с JIRA. Однако, поиск и локализация проблем — не единственная задача, с которой типовой процесс разработки сталкивается каждый день, и даже несколько раз в день. Более важной задачей является сохранение целостности проекта в процессе внесения дополнений и исправлений в код. Для этих задач вы можете использовать CI-сервер, который в том числе позволяет создавать сборки проектов и выполнять серии тестов для автоматической проверки функциональности.

Bitbucket «из коробки» предлагает интеграцию с родственным решением от Atlassian — Bamboo. Но, помимо Bamboo, существуют другие CI-решения, которые также достаточно популярны — TeamCity и Jenkins. В нашем посте мы обрисуем специфику интеграции Bitbucket и TeamCity.

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


Скала Улуру в Австралии как пример монолита — КДПВ, не более

Что такое монорепозиторий?

Определения разнятся, но мы будем считать репозиторий монолитным при выполнении следующих условий:

• Репозиторий содержит более одного логического проекта (например, iOS-клиент и веб-приложение)
• Эти проекты могут быть не связаны, слабо связаны или связаны сторонними средствами (например, через систему управления зависимостями)
• Репозиторий большой во многих смыслах:
  
  • По количеству коммитов
  • По количеству веток и/или тегов
  • По количеству файлов
  • По размеру содержимого (то есть размеру папки .git)

С удовольствием делюсь новостью, которая, надеюсь, порадует некоторых читателей Хабра: в Bitbucket Server вот-вот появится возможность поиска по коду. Буквально на днях вышел релиз по программе раннего доступа (EAP).

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

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

Один из принципов дизайна в Atlassian — лаконичность. В ходе эволюции UX некоторые непопулярные действия, расчитанные на опытных пользователей, были спрятаны в выпадающих списках или за горячими клавишами. Там они ждут предприимчивого пользователя, который случайно наткнётся на них благодаря случайному нажатию клавиш или клику мышки (ну, или заглянет в руководство). Вот шесть моих любимых трюков Bitbucket Cloud, о которых вы, возможно, никогда не слышали:

Омнибар

Омнибар в Bitbucket — это строка быстрого доступа к действиям, похожая на ⇧⇧ в средах разработки JetBrains или ⌘+P в Sublime Text. Запустить омнибар можно на любой странице, нажав клавишу точки.

По умолчанию, он покажет набор действий, соответствующих текущему контексту:

Все мы в IT сталкивались с системами отслеживания ошибок — с так называемыми баг-трекерами, с issue-трекерами. Один из популярных продуктов такого рода — Atlassian JIRA.

На самом деле, Atlassian JIRA — это больше, чем просто система отслеживания ошибок. JIRA может использоваться довольно широко — в том числе и для управления проектами. Можно сказать, что JIRA — это система для отслеживания статуса задач. Задачи могут быть разными: это сбор требований, тестирование, непосредственно разработка и т. д. Я видел даже попытки подсадить на JIRA бухгалтеров — а что, мол, будет у нас agile-бухгалтерия!

На официальном же сайте JIRA описывается следующим образом:
JIRA is the tracker for teams planning and building great products. Thousands of teams choose JIRA to capture and organize issues, assign work, and follow team activity. At your desk or on the go with the new mobile interface, JIRA helps your team get the job done. В общем, основная идея JIRA в том, что она позволяет планировать работу.

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

Atlassian Confluence — мощное решение для развертывания Enterprise Wiki в организации (хотя, нет никаких технических проблем с тем, чтобы использовать его и дома — лицензия на 10 пользователей стоит всего 10 американских долларов в год). И лично мне Confluence нравится тем, что имеет дружелюбный интерфейс и позволяет интуитивно понятно редактировать контент, с легкостью дополняя его визуальными составляющими, что позволяет в итоге получить красивые и удобные для просмотра страницы. Кстати, этот пост тоже написан в Confluence.

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

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

Bitbucket анонсировал «Atlassian connect for Bitbucket»: возможность создавать плагины, встраиваемые в облачную часть Bitbucket, расширяющие его интерфейс и добавляющие новые возможности. Это качественный рывок в борьбе между Bitbucket, Github, Gitlab и TFS: если раньше мы были ограничены вебхуками и REST API, то теперь появилась возможность допиливать «под себя» и для других разработчиков непосредственно облачный интерфейс. Ужа доступно несколько расширений, основанных на nodejs SDK для создания плагинов и документация.

JIRA широко используется в Mail.Ru Group. Сейчас мы применяем эту систему не только для управления проектами и отслеживания ошибок, но и для организации самых разнообразных операционных процессов — рекрутинга, согласования договоров, командировок и так далее. Это с одной стороны очень удобно, так как многие бизнес-процессы отлично ложатся на модель Issue в JIRA. Однако часто требуются также и специфичные функции, реализуемые с помощью специально написанных нами плагинов.

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

Сейчас многие JIRA-плагины сторонних разработчиков не могут похвастаться качественным интерфейсом. Это касается даже некоторых платных плагинов. Однако все средства для быстрой разработки удобных и красивых интерфейсов есть. В статье рассматривается одно из них — AUI Framework (Atlassian User Interface Framework).

Предполагается, что читатель знаком с тем, как можно сделать плагин в принципе. Если нет, то об этом можно почитать, например, здесь.

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

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

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

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

В данной статье попробуем понять, что нового нам стоит ждать в новой версии JIRA.

Распространённая проблема менеджера проектов — определить, от кого зависит дальнейшее исполнение задачи. Часто задача назначается на разработчика, да так и остаётся “висеть” на нём вплоть до релиза. Однако разработчик отвечает только за часть исполнения. QA — тестирует, DevOps — включает в релиз, продакт-менеджер — оценивает готовую работу (в каждой организации эта цепочка своя). Задача путешествует от статуса к статусу (In Progress, Done, Tested, Shipped, Closed и т.п.), но исполнителем значится всё тот же разработчик.

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

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

Сегодня на свой электронный ящик я получил приглашение на участие в конкурсе от Bitbucket. В нём говорится, что сервис репозиториев Bitbucket достиг порога в 1 миллион пользователей, в связи с чем устраивается конкурс с главным призом — поездка на хакатон в Сан-Франциско.

Казалось бы, совсем недавно вышел Confluence 5, который принес пользователям уйму новых фич: новое визуальное представление, возможность переключения между приложениями непосредственно из wiki, нотификации о том, что добавлен комментарий либо содержимое страницы кем-либо изменено. Тем не менее, уже ощущается дыхание версии 5.1 Atlassian Confluence, которая направлена на упрощение процесса содания страниц с помощью технологии Blueprints. Blueprints помогает пользователям понять, какое содержимое они хотят создать и показываeт, как это сделать, буквально проводя пользователей за руку до получения готовой к просмотру wiki-страницы.

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

За несколько дней до весны в линейке продуктов компании Atlassian большое и, самое главное, долгожданное событие: случился релиз Confluence 5 с ощутимыми изменениями в пользовательском интерфейсе и огромным количеством новых фич. Под катом обзор возможностей Confluence 5 с некоторым количеством картинок и большим количеством ссылок.

CEO Atlassian как бы говорит нам, что они отлично потрудились над Confluence 5