Как работали с Bitbucket и какими инструментами?

Что проверяют

Работали ли вы с Bitbucket как с частью процесса поставки, а не только как с местом, куда делаете git push. Следом обычно спрашивают, как был устроен пайплайн сборки и что происходило с pull request до слияния.

Как отвечать

Опирайтесь на свой проект и сразу уточните редакцию: Bitbucket Cloud или self-hosted Bitbucket Data Center. От этого зависит, что было доступно. Редакция Server снята с поддержки в феврале 2024 года, если работали на ней, так и скажите.

Каркас ответа:

• ветки и права: модель ветвления, защита main или develop через branch permissions, запрет прямого пуша;
• pull request: default reviewers, merge checks (минимум апрувов, зелёная сборка, закрытые задачи ревью), выбранная стратегия слияния: merge commit, squash или fast-forward;
• сборка: Bitbucket Pipelines с bitbucket-pipelines.yml либо внешний Jenkins, TeamCity или Bamboo по вебхуку. Для Java назовите конкретику: mvn verify или ./gradlew build, прогон тестов, кеш зависимостей, публикация артефакта в Nexus или Artifactory;
• качество: SonarQube с результатами прямо в PR, отчёты о покрытии JaCoCo;
• Jira: ключ задачи в названии ветки и коммита, smart commits вроде PROJ-123 #comment, автоматическая связка PR с задачей;
• ваша роль: настраивали ли пайплайн сами или пользовались готовым, разбирали ли упавшие сборки.

Если с Bitbucket не работали, скажите, что знакомы с GitHub или GitLab, и покажите, что понятия переносятся: PR, защита веток, CI по событию. Разница в основном в интерфейсе и синтаксисе конфигурации пайплайна.

Где спотыкаются

Рассказывают только про git commit и git merge. Это ответ про Git, а спрашивали про платформу вокруг него.

Приводят цифры вроде «деплой ускорился на 30%», не зная, как их посчитали. Лучше честное «сборка шла 12 минут, после кеша зависимостей стала 5», если вы это действительно помните.

Путают Pipelines с внешним CI и не могут ответить, где лежала конфигурация сборки и кто её менял.