Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.
До 2020 года я работал конструктором (разрабатывал электронику и электрику). Сейчас я сменил сферу деятельности, но считаю важным поднять вопрос, который возник в свое время пока он совсем не выветрился из головы. В статье затронута важность разработки стандартов в команде hardware разработчиков, а также приведен пример одного из стандартов для ведения репозитория для сборку.
/target // скрипты для сборки ядер
/toolchain // скрипты для сборки gcc, musl и прочих инструментов сборки
/feeds // дополнительные репозитории с приложениями
/package // скрипты для сборки приложений
...
В GitLab мы всегда думаем о том, как помочь пользователям снизить риски, повысить эффективность и скорость поставки на вашей любимой платформе. В этом месяце мы добавили немало полезных новшеств, которые расширяют возможности безопасности, снижают количество уязвимостей, повышают эффективность, упрощают работу с GitLab и помогают вашей команде поставлять фичи ещё быстрее. Мы надеемся, что вам пригодятся основные фичи релиза, а также 53 другие новые фичи, добавленные в этом релизе.
Большинство из нас, подмечая очередной новый термин в IT блогосфере или конференции, рано или поздно задается подобным вопросом: “Что это? Очередное модное слово, “buzzword” или действительно что-то стоящее пристального внимания, изучения и обещающее новые горизонты?” Точно также вышло у меня и с термином GitOps некоторое время назад. Вооружившись множеством уже существующих статей, а также знанием коллег из компании GitLab, я попытался разобраться, что же это за зверь, и как его применение может выглядеть на практике.
Автоматизация рабочего процесса Java-проекта с помощью модифицированной модели ветвления Gitflow
Разделение функций с использованием изолированных ветвей позволяет вам решить, какие функции включать в каждый релиз. Компромисс здесь может заключаться в сложных слияниях.
Как все знают, монорепозиторий - это несколько частей проекта (приложения, сервисы, библиотеки и т.д.), которые хранятся в одном репозитории. Плохо это или хорошо - не тема данной публикации. Но все же упомяну некоторые причины по которым я решил их использовать.
В скриптах деплоймента (или в моем случае еще и в настройках GitLab репозитория), нужно сформировать токены/ключи доступов к докер реджистри, кубернетесу, разным кластерам и т.д. И если у вас пару сервисов, то это не проблема, но если сервисов 15-20, то это весьма болезненный процесс. Особенно, когда настройки кластера меняются и нужно эти изменения вносить во все репозитории.
В определенных случаях среди нескольких сервисов, можно выделить общий код, который можно переиспользовать (описание интерфейсов, утилиты и т.д.) и особенно важно на самом старте проекта, когда эти общие куски кода только формируются не тратить время на коммиты в отдельные репозитории, если нужно всего лишь добавить поле в общий интерфейс.
После того как мы перешли на монорепозиторий появилось еще несколько преимуществ, без которых, в принципе, тоже можно жить, но все равно это был приятный бонус.
И вот мы решили использовать монорепозиторий, но с чего начать и как все организовать?
Вы используете семантический подход к управлению версиями? Вы используете gitflow? Скорее всего, вы знакомы с процессом корректировки версий, создания веток, слияния с master/dev, повторной корректировки версий, борьбы с конфликтами слияния,…
В этой статье я кратко объясню процесс выпуска, который мы, по сути, используем для наших библиотек, и то, как мы его автоматизировали. Обычно мы используем подход CI/CD, используя номера сборок, но для наших библиотек мы решили использовать семантическое управление версиями. Я столкнулся с утомительным процессом выпуска, который сопровождает это в нескольких компаниях, и теперь я наконец нашел решение.
Я разработчик игр и мобильных приложений. Я написал немало кода на C++ и Swift. И, как и многие из вас, я пользуюсь системами контроля версий, в частности, гитом.
Гит имеет максимально функциональный command-line интерфейс и десятки если не сотни приложений для работы с ним локально при помощи графического интерфейса, которые умеют выполнять только часть функционала гита. Беда в том, что я пишу код уже 10 лет, но никак не нашел идеальный (подходящий для меня) git GUI клиент. Пример: недавно вышел Github Desktop. Я его использовал до тех пор, пока мне не понадобилось сделать checkout на конкретный коммит. И я испытал уже привычную боль от того, что данное приложение так делать не умеет. И вновь вернулся в терминал (с автодополнением для гита). И такие вещи есть в каждом GUI приложении для гита. Однако, я сюда пришел не критиковать их. Уверен, что вы и без меня имеете много претензий к этим приложениям. Я долго думал о том каким должно быть идеальное git GUI приложение. Это были мимолетные обрывки желаний, из которых трудно собрать что-то цельное. И совсем недавно эти обрывки мыслей у меня собрались в единую картину. Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.
Не только разработчикам-новичкам, но и ярым профессионалам приходится прибегать к отмене каких-либо изменений. И тогда, первое, что приходит на ум, — это команда git revert, как самый безопасный способ. И тут есть подводные камни, про которые я хочу рассказать.
Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:
Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!
Сегодня я хочу поделиться с вами небольшим bash-скриптом, который я успешно использую уже в течение нескольких лет.
Для начала опишу ситуацию, часто у меня возникающую и по сей день, которая и сподвигла на написание скрипта. Во время работы над новой задачей я периодически сохраняю текущее состояние проекта в гите, при этом сами коммиты не несут никакой смысловой нагрузки ни по содержанию ни по коммит-сообщениям.
В результате локальная ветка законченной задачи выглядит примерно так:
git push -f». Поскольку это одна из сотен максим, которые нужно усвоить начинающему инженеру-разработчику ПО, никто не тратит время на уточнение, почему именно так нельзя делать. Это как младенцы и огонь: «спички детям не игрушки» и баста. Но мы растём и развиваемся как люди и как профессионалы, и однажды вопрос «а почему, собственно?» встаёт в полный рост. Эта статья написана по мотивам внутреннего митапа на тему: «Когда можно и нужно переписывать историю коммитов», который я проводил, когда работал в компании FunCorp.В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части!
Целью всего этого проекта является создание серверной части для моего будущего архива содержимого, который будет размещен на моем сайте. Однако всякий раз, когда я обновляю серверную часть или меняю схему GraphQL, мне придется выполнять полное развертывание службы снова.
Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно?
Вот почему мы будем использовать GitHub Actions
В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.
DevSecOps помогает командам обнаруживать и устранять неисправности и уязвимости на ранних стадиях разработки ПО. В GitLab 13.3 создавать безопасное программное обеспечение стало проще благодаря тестированию фаззингом, интегрированному в ваш рабочий процесс разработки. Фаззинг-тестирование, направленное на полное покрытие кода, вместе с запуском DAST (динамического тестирования безопасности приложений) по требованию помогут обнаруживать реальные уязвимости программного обеспечения быстрее и эффективнее. Кроме того, с новой матрицей сборки для CI/CD станет проще выпускать релизы более часто. Наконец, панель состояния подов повысит эффективность работы специалистов по эксплуатации за счёт сокращения переключений контекста: все данные о состоянии подов Kubernetes теперь находятся в одной панели. Мы надеемся, что вам понравятся основные фичи релиза, а также ещё 69 новых фич, включённых в этот релиз.
