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

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

Перед нашей командой встала задача упростить жизнь нашим прикладникам. Мы разбалованы современными фишками из Visual Studio, ReSharper и IDEA. Прикладники требовали от нас внедрить в инструмент работу с git "из коробки".

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.

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

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.

Рассмотрим такие темы как:

• Git 101
• Методологии разработки (Git flow)
  
  • GitHub flow
  • GitLab flow
• GitLab
• GitLab CI

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



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.

Непрерывная интеграция, поставка и развертывание являются основополагающими принципами DevOps. В GitLab включена функциональность CI/CD, которая пришлась по душе как разработчикам и аналитикам, так и компаниям в целом.

Всем привет!

Мы тут немного переделали наш курс посвящённый web-разработке и добавили ещё целый месяц изучения JS. Ну и как обычно у нас — рассмотрим что-нибудь интересное, что разбирается у нас на курсе. В данном случае — git rebase.

Поехали.

Что на самом деле происходит во время git rebase, и почему вас должно это волновать.

Основы rebase-а

Таким вы могли бы представить себе rebase в git:

Alyson La, Data science в GitHub: В октябре этого года я отпраздновала свой пятилетний юбилей работы в GitHub. 5 лет назад я была бухгалтером, который ничего не знал о программировании, не говоря уже об использовании Git и GitHub.

Теперь я энтузиаст Data Scientist, который знает некоторые вещи о написании кода с помощью Git & GitHub. Частично благодаря изучению этих технологий я сделала этот карьерный переход.

Но даже работая в GitHub, изучать Git и GitHub было сложно! Поэтому я хочу поделиться 5-ью советами по использованию GitHub с другими людьми, новичками программирования.

Совет № 1: Измените редактор по умолчанию

Для многих людей текстовый редактор при использовании Git через терминал — VIM. VIM может быть ужасным, страшным для нового или казуального хакера. Или даже для ветеранов-хакеров как @haacked.


Если вы когда-нибудь столкнетесь с конфликтами слияния (а вы их встретите, см. совет №4), вы попадете в VIM, чтобы исправить конфликт, и вам нужно будет знать конкретные команды VIM для редактирования документа иначе вам захочется плакать. Больше года у меня была заметка на мониторе для напоминания основных команд VIM, таких как i (для редактирования) и: wq (для сохранения и выхода). Чтобы избежать боли, вы можете просто выбрать другой текстовый редактор.

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

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

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

Перевод статьи "Шон Пирс: настоящий лидер" — о человеке, который является основателем многих проектов, в том числе jGit и Gerrit Code Review.

29 января 2018, скончался Шон Пирс, известный программист, автор, коммиттер и основатель многих проектов, в том числе Git, Jgit, libgit и Gerrit Code Review.

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

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

В первом релизе 2018 года мы внесли улучшения в процессы планирования, тестирования, развертывания и работы с мерж-реквестами. Кроме того, в данный релиз включены новые возможности тестирования безопасности, а также первая версия Web IDE, который является частью нашего амбициозного проекта Complete DevOps.

Хотя большинство PHP-разработчиков умеют пользоваться Composer, не все делают это эффективно или лучшим возможным образом. Поэтому я решил собрать советы, которые важны для моей повседневной работы. Большинство из них опираются на принцип «От греха подальше»: если что-то можно сделать несколькими способами, то я выбираю наименее рискованный.

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

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

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

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

Из всех моих разговоров с коллегами о разных аспектах разработки программного обеспечения одна тема всплывает чаще других. Да что там «чаще» — она повторяется снова и снова, как заезженная пластинка — это беседы на тему того, чем плох GitFlow и почему его стоит избегать.

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

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

Я называю эту стратегию ThreeFlow потому, что в ней есть ровно три ветки. Не четыре. Не две. Три.

В честь окончания года, для праздничного «айтишного» настроения: 550+ репозиториев команды SEMrush на одном видео.


Спонсор показа Gource

Под катом пара слов о том, как это сделано.