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

Отказ от поддержки Mercurial обосновывают оптимизацией проекта и фокусировкой на более актуальных для миллионов пользователей BitBucket инструментов. Конкретно речь идет о фокусировке на работе с Git-репозиториями. К 1 июня 2020 года из BitBucket Cloud и API проекта поддержка Mercurial будет полностью удалена.

Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится, но вроде большинство разработчиков их и не пишет. Во всяком случае я изредка пишу только скрипты для автоматизации. Если у вас Visual Studio, можно воспользоваться красивым плагином.

Локальные репозитории, команды на бумажке и прочая оставим для студентов и лабораторных работ, которых на весь интернет вагоны. Так как единственный бенефит Mercurial для простых смертных это работа в офлайне, этим и надо пользоваться. То есть, основной репозиторий создаём в онлайне: Mercurial сейчас поддерживает Microsoft и Google (вот удивительно!), поэтому апологеты могут выбрать любимую корпорацию без мучений. Но с одним нюансом, у MS не работает русский в комментариях к коммитам.

Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

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

Подробности можно узнать тут.
Spooning происходит от англ spoon(ложка) по аналогии с forking — fork(вилка)

Многие из нас ежедневно используют в работе распределенные системы управления версиями, самыми популярными из которых сейчас безусловно являются Git и Mercurial. Для большей гибкости в работе исходные коды для проектов под контролем таких систем зачастую хранятся не локально, а на закрытых серверах компаний или в облачных сервисах наподобие Github или Bitbucket. Такие сервисы предоставляют разработчикам ПО, дизайнерам, писателям и людям других профессий, в чьи обязанности входит создание контента при помощи компьютеров, совместно работать над своими задачами, получать доступ к общим вики и планировщику задач и изучать продукты труда других пользователей, открытые для просмотра в публичных репозиториях.

Разные облачные сервисы по-разному подходят к вопросу оплаты за свои услуги. Так, наверное самый популярный на данный момент сервис «социального кодинга» GitHub разрешает бесплатно работать над любым количеством открытых проектов, но работа с закрытыми репозиториями возможна только для платных аккаунтов. Сервис BitBucket от известного австралийского поставщика систем совместной разработки Atlassian пока популярен не так, но его политика в плане привлечения новых клиентов более гибкая. В BitBucket вы можете бесплатно создавать любое количество закрытых для просмотра со стороны репозиториев, но принимать участие в работе над вашими бесплатными закрытыми проектами может не более пяти человек. При необходимости увеличении их числа вам придется покупать платный доступ к сервису.

В то время как многие из проектов можно вполне свободно выкладывать в общий доступ, разумеется есть и такие, которые надо хранить вдали от посторонных глаз, но работать над ними большими командами. Самым правильным выходом здесь будет покупка тарифного плана на одном из облачных сервисов или установка системы управления версиями на свой локальный сервер. Если же вам по каким-то причинам все же хочется получить полностью безлимитный доступ к BitBucket, аналогичный покупке тарифного плана за $80 в месяц (хотя бы затем, чтобы просто наслаждаться им, как вы радуетесь заполненному на 3,5% бесплатному пятидесятигигабайтному аккаунту на Дропбоксе), прошу под кат.

Bitbucket — это хостинг для Mercurial и Git репозиториев. Ближайший аналог и прямой конкурент — github. По популярности Bitbucket отстаёт, однако у него есть пара заметных фич по сравнению с github — это поддержка Mercurial и возможность создать сколь угодно приватных репозиториев на бесплатном аккаунте, однако дать доступ можно максимум пяти пользователям (у github вообще нет приватных репозиториев для бесплатных аккаунтов).

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

Доброго времени суток, уважаемое сообщество.
Решил поделиться небольшой идеей, возможно кому-то будет интересно и полезно.

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

Привет, сообщество!

В честь 1 миллиона своих пользователей сервис Bitbucket.org предлагает купить лимитированную серию футболок со своим брендом со скидкой 50% на дочернем сервисе компании AtlassianSwag. Стоимость такой футболки $20. Сервис (bitbucket) даёт купон на скидку $10 при приглашении в репозиторий новых пользователей.

В этой статье мы поговорим про анонсы и коммерческую доступность сервиса Windows Azure Web Sites.

Windows Azure Web Sites

Windows Azure Web Sites — это сервис предназначенный для быстрого создания новых или размещения существующих веб-приложений в надежном, масштабируемом облачном окружении.

Ключевыми особенностями Windows Azure Web Sites являются:

• Поддержка разнообразных платформ и языков программирования для размещения веб-приложений;
• Непрерывная интеграция со службами и системами контроля версий;
• Публикация готовых приложений, фреймворков и CMS за две минуты из галереи шаблонов;
• Масштабирование по требованию и автоматическое масштабирование вычислительных ресурсов на основе заданных правил;
• Подробные мониторинг, ведение логов и диагностика через панель администрирования;
• Удобное конфигурирование, поддержка SSL, привязка собственных доменов, поддержка 32 и 64-битного размещения;
• Гибкое ценообразование: бесплатный тариф, быстрое масштабирование сайта на другие тарифы при росте приложения.

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

Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

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

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

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

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

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

Привет, Хабр. Этим постом мы начинаем наши пятничные новостные выпуски, в которых будем рассказывать о новых технологиях, поддержку которых мы внедрили в наш проект, а также о фичах, которые сделают работу с Vexor максимально продуктивной. Наша команда учитывает пожелания пользователей, и постепенно мы расширяем наш функционал.
Напомним, что Vexor CI – облачный continuous integration сервис для разработчиков с неограниченными ресурсами и поминутной оплатой, позволяющий эффективно тестировать проекты.

Сразу заинтригую: в результате мы получим связку бесплатного приватного git репозитория на Bitbucket и бесплатный* Continious Integration сервер (SAAS), который будет собирать проект и прогонять все тесты после каждого пуша.
* — бесплатная подписка дает возможность тестировать 5 приватных репозиториев и максимум 100 билдов в месяц.

Мне этого для личного проекта достаточно.

Приведу пример для PHP, проект на Symfony2, но данный сервис поддерживает ещё и Ruby, Node.js, Python.

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

Доброго дня, Хабр!

Спешу рассказать вам, что совсем недавно вышла новая версия нашего баг-трекера — YouTrack 6.5!



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

Много статей (в том числе и на Хабре) посвящено подключению к Git по SSH-ключам. Почти во всех из них используется один из двух способов: либо с помощью puttygen.exe, либо командами ssh-keygen или ssh-add.

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

Как я решил эту проблему — под катом.

Практически во всех местах моей работы программистом для разработки использовали всего два продукта: багтрекинг и систему контроля версий. Чаще всего это были Atlassian Jira и SVN. В принципе, наличие этих двух систем здорово упорядочивает общение всех участников процесса разработки и положительно влияет на качество работы отдела и продукта.

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

После третьей страницы текста моей статьи, я решил разделить ее на 2 блока:

• Настройка ПО, сопровождающего процесс разработки.
• Описание Workflow.

Итак. Настройка ПО, сопровождающего процесс разработки

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

Работа в основном в стиле стартапа, когда нет конкретной и подробной постановки. Очень часто эксперименты вроде “а давайте попробуем так, посмотрим что получится” или “вы классно все сделали, но теперь надо все совсем по-другому”.
За эти годы концепцию нашей работы можно описать одной фразой — это “стремительная смена концепции”.
Понятное дело, что применить в таких условиях различные методологии никак не удавалось.

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.