Pull to refresh
  • by relevance
  • by date
  • by rating

Удачная модель ветвления для Git

Git *
Translation
Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Читать дальше →
Total votes 180: ↑171 and ↓9 +162
Views 861K
Comments 105

Процесс Code Review с Atlassian Stash

Arcadia corporate blog Git *
Всем привет! Вот и наша компания решила завести блог на Хабре (в конце концов, не вечно же читать чужие статьи). В профиле компании вы можете посмотреть, чем мы занимаемся. В ближайшее время мы предложим вашему вниманию цикл статей по широкому спектру тем: от сервисов дистрибуции и поддержки тестовых сборок iOS приложений до программного управления IIS. А первая наша публикация посвящена Atlassian Stash.



На текущий день на хабре практически отсутствует какая бы то ни было информация об Atlassian Stash (всего один анонс и одна статья на тему установки). Хотя инструмент, на самом деле, прекрасный, и определенно стоящий рассмотрения в случае использования всего стэка Atlassian. Я хочу рассказать что это такое и как эту штуку можно добавить в процесс разработки.
Читать дальше →
Total votes 15: ↑12 and ↓3 +9
Views 31K
Comments 33

Continuous Integration с Unity

Development of mobile applications *Game development *
Tutorial
С переходом на новый проект на Unity с относительно большой командой разработчиков резко встала необходимость автоматической сборки и доставки приложения на устройства для тестирования. Вот как с этим обстояла ситуация, когда я пришел на проект (под iOS):
  1. На отдельной mac-машине проект вручную выкачивался из репозитория (Asset Sever).
  2. Вручную (File->Build Settings->Build & Run) запускалась сборка в xCode-проект.
  3. Далее в xCode делался архив (Archive).
  4. Архив экспортировался в ipa-файл, который вручную загружался в TestFlight.
  5. Далее, уже в TestFlight доступ предоставлялся нужным тестерам.

Все описанное выше автоматизируется с помощью так называемой непрерывной интеграции (англ. Continuous Integration, CI). На моих предыдущих проектах для этих целей использовался TeamCity от JetBrains (создателей удобного инструмента рефакторинга кода Resharper). TeamCity (TC) — очень мощный программный продукт, выполняющий цели, поставленные перед системой непрерывной интеграции, на все 100%. Он умеет даже больше. Но речь в статье пойдет не о нем (о нем уже есть статьи на хабре), а о новом сервисе Unity Cloud Build, специально для разработчиков на движке Unity.

UPD. Unity выпустила Unity Cloud Build в свет, а я обновил статью :) Об изменениях и нововведениях читайте ниже.
Читать дальше →
Total votes 19: ↑19 and ↓0 +19
Views 18K
Comments 20

Модель ветвления и управления модулями git для большого проекта

РЕЛЭКС corporate blog Git *Version control systems *
Без малого два года назад мы начали использовать в разработке нашего флагманского проекта СУБД ЛИНТЕР новую модель ветвления и управления подмодулями git-а. Десятки тысяч коммитов, сделанные за это время группой разработчиков, позволяют с определенной долей уверенности считать нововведения успешными. Эта статья — краткий обзор принципов организации хранилища исходных кодов в большом проекте на базе альтернативной реализации модулей git, сложившейся стратегии ветвления и инструментария linflow.


Читать дальше →
Total votes 29: ↑26 and ↓3 +23
Views 34K
Comments 8

GitFlow и Semantic Versioning на каждый день

Website development *Programming *.NET *Version control systems *C# *
Translation
image

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

Возможно причина в том, что я выбрал не самый оптимальный путь, и это может стать хорошей темой для будущего поста. В этом же я хочу описать простой подход к управлению релизами приложений и библиотек.
Читать дальше →
Total votes 18: ↑17 and ↓1 +16
Views 27K
Comments 3

Efficient Rails — новая книга по оптимизации процесса разработки Rails-приложений

Ruby *Programming *Ruby on Rails *Professional literature


Эффективные Рельсы — более точного названия для книги придумать было бы сложно. Всё содержание описывается этими двумя словами и раскрывается для нас в сотне рецептов на 380+ страницах. В ожидании выхода финальной версии Rails 5, данное чтиво — то, на что стоит потратить время, благо потребуется его не так много. Но данное вложение вернётся колоссальной прибылью знаний и позволит, как говорится на обложке, «создавать Rails-приложения с нечеловеческой скоростью». Да и не только Rails, да и не только Ruby. Первые две главы включают в себя обилие информации по работе с терминалом и СКВ. Подробности под катом.
Узнать подробнее и получить промокод
Total votes 10: ↑9 and ↓1 +8
Views 9K
Comments 16

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

AT Consulting corporate blog Programming *Git *Version control systems *

Немного истории


В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.


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



Git


Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.

Читать дальше →
Total votes 27: ↑27 and ↓0 +27
Views 38K
Comments 117

GitLab Flow

Softmart corporate blog Git *Version control systems *
Translation

Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:




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


  • Не описан точным образом весь рабочий процесс,
  • Вносится ненужная сложность,
  • Нет связи с трекером задач (issue tracker).

Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:



Читать дальше →
Total votes 29: ↑29 and ↓0 +29
Views 77K
Comments 21

Как подружить этапы разработки с gitflow

Development Management *Project management *
Sandbox

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

Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 14K
Comments 16

От 15 и больше: как обеспечить масштабируемость CI

Wrike corporate blog IT Infrastructure *Server Administration *Development Management *DevOps *


Сейчас публикуется много статей и докладов про конкретные технологии в DevOps: Docker, Kubernetes, Ansible… Я же хочу поговорить про построение процессов и про то, как мы в Wrike за два с половиной года эволюционировали от релизной системы для 15 фронтенд-разработчиков до почти 60-ти, и 2-3 деплоев в день.

Эта статья — про те уроки, которые мы на этом пути решили. Статья основана на моем докладе для DevOps митапа в Wrike Tech Club. Если некогда читать, есть видеозапись презентации. Читатели, добро пожаловать под кат.
Как это было...
Total votes 15: ↑15 and ↓0 +15
Views 4.3K
Comments 0

Стратегия ветвления ThreeFlow

Инфопульс Украина corporate blog Git *Version control systems *GitHub Development Management *
Translation
Из всех моих разговоров с коллегами о разных аспектах разработки программного обеспечения одна тема всплывает чаще других. Да что там «чаще» — она повторяется снова и снова, как заезженная пластинка — это беседы на тему того, чем плох GitFlow и почему его стоит избегать.

Статья "Удачная модель ветвления для Git" описывающая метод, получивший в последствии название «GitFlow» стала де-факто стандартом того, как нужно начинать использовать Git в вашем проекте. Если поискать в Google что-то типа "git branching strategy" то вот как раз этот метод будет описан по первой ссылке (а скорее всего и по нескольким следующим).

Лично я ненавижу GitFlow и за последние годы убедил много команд разработчиков перестать его использовать, чем, как мне кажется, сохранил им уйму времени и нервов. GitFlow заставляет команды организовывать управление изменениями кода хуже, чем оно может быть реализовано. Но поскольку это такой популярный метод (по крайней мере в результатах поисковика), то команды без достаточного опыта, которые ищут «что-то, хотя бы как-то работающее» находят именно его при быстром поиске, да ещё и видят слово «успешный» прямо в заголовке статьи с его описанием — ну и начинают бездумно использовать. Я хочу хотя бы немного изменить этот паттерн поведения, описав в этой статье более простую и не менее успешную стратегию использования веток Git, которую я внедрил во многих командах. Часто эти команды пробовали использовать GitFlow, но испытывали проблемы, которые, пропали с переходом на ThreeFlow.

Я называю эту стратегию ThreeFlow потому, что в ней есть ровно три ветки. Не четыре. Не две. Три.
Читать дальше →
Total votes 57: ↑29 and ↓28 +1
Views 17K
Comments 52

GitHub Flow

Git *GitHub
Recovery mode
Translation
Tutorial

Увидев в очередной раз базворд GitFlow я психанул и решил перевести описание более простой и менее проблемной схемы работы с ветками под названием GitHub Flow. Именно её имеет смысл использовать по умолчанию, переходя к какой-то другой лишь в случае непреодолимых обстоятельств.


Создайте ветвь



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

Читать дальше →
Total votes 48: ↑32 and ↓16 +16
Views 69K
Comments 22

О терниях и звездах на пути оптимизации процессов разработки

Development Management *Project management *Agile *Start-up development Personnel Management *
Sandbox

Мечты, мечты


Холодными осенними вечерами мы с разработчиками приложений 3D визуализации собирались на кухне… пили кофе… и думали о ней… об эталонной организации разработки.

— У меня знакомые по agile работают: спринты, стори поинты, все дела…
— Да нам бы хотя бы ревью…


Читать дальше →
Total votes 23: ↑19 and ↓4 +15
Views 6.3K
Comments 3

Организация хранения кода в GitLab и интеграция код ревью в GitFlow

Neoflex corporate blog Git *

Не так давно на одном из проектов нашей компании было принято решение наконец отказаться от использования Subversion для хранения и версионирования кода в пользу Git.



Основными целями перехода были следующие:


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

Читать дальше →
Total votes 14: ↑12 and ↓2 +10
Views 12K
Comments 10

Как машинное обучение в YouDo катится в продакшен. Лекция в Яндексе

Яндекс corporate blog Industrial Programming *Machine learning *
В крупных сервисах решить какую-нибудь задачу с помощью машинного обучения — означает выполнить только часть работы. Встраивать ML-модели не так уж просто, а налаживать вокруг них CI/CD-процессы еще сложнее. На конференции Яндекса «Data & Science: программа по заявкам» руководитель направления data science в компании YouDo Адам Елдаров рассказал о том, как управлять жизненным циклом моделей, настраивать процессы дообучения и переобучения, разрабатывать масштабируемые микросервисы, и о многом другом.


— Начнем с вводных. Есть data scientist, он в Jupyter Notebook пишет какой-то код, делает фиче-инжениринг, кросс-валидацию, тренирует модельки. Скор растет.
Total votes 23: ↑22 and ↓1 +21
Views 9.3K
Comments 8

Качество кода

Конференции Олега Бунина (Онтико) corporate blog Website development *JavaScript *Programming *Perfect code *
Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

Total votes 54: ↑48 and ↓6 +42
Views 30K
Comments 40

Эволюция CI в команде мобильной разработки

Конференции Олега Бунина (Онтико) corporate blog Авито corporate blog Development of mobile applications *IT Infrastructure *Development for Android *
Сегодня большинство программных продуктов разрабатываются в командах. Условия успеха командной разработки можно представить в виде простой схемы.



Написав код, вы должны убедиться, что он:

  1. Работает.
  2. Ничего не ломает, в том числе код, который написали ваши коллеги.

Если оба условия выполняются, то вы на пути к успеху. Чтобы легко проверять эти условия и не сворачивать с выгодного пути, придумали Continuous Integration.

CI — это рабочий процесс, при котором вы как можно чаще интегрируете свой код в общий код продукта. И не просто интегрируете, а еще и постоянно проверяете, что все работает. Так как проверять нужно много и часто, стоит задуматься об автоматизации. Можно все проверять на ручной тяге, но не стоит, и вот почему.
Total votes 45: ↑45 and ↓0 +45
Views 12K
Comments 3

werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада)

Флант corporate blog System administration *Build automation *DevOps *Kubernetes *
27 мая в главном зале конференции DevOpsConf 2019, проходящей в рамках фестиваля РИТ++ 2019, в рамках секции «Непрерывная поставка», прозвучал доклад «werf — наш инструмент для CI/CD в Kubernetes». В нём рассказывается о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая возможные пути решения, мы показываем, как это реализовано в Open Source-инструменте werf.

С момента выступления наша утилита (ранее известная как dapp) преодолела исторический рубеж в 1000 звёзд на GitHub — мы надеемся, что растущее сообщество её пользователей упростит жизнь многим DevOps-инженерам.



Итак, представляем видео с докладом (~47 минут, гораздо информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!
Total votes 43: ↑43 and ↓0 +43
Views 17K
Comments 0

Пожалуйста, перестаньте рекомендовать Git Flow

Флант corporate blog Programming *Git *
Translation
Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.
Читать дальше →
Total votes 98: ↑89 and ↓9 +80
Views 128K
Comments 174

Собираем свой flow для git с нуля

Programming *Git *Version control systems *Development Management *Project management *

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).


Ее основными тезисами были:


  • GitFlow противоречит тезису "ветки должны быть короткоживущими".
    Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
  • GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
    Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
  • GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
  • GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
  • Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.


    Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.



Так что делать-то?

Читать дальше →
Total votes 23: ↑21 and ↓2 +19
Views 14K
Comments 48
1