Git *

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

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

Если вы сделали опечатку, когда вводили имя ветки, вам поможет вот такая команда.

Итак, у вас есть длинные лабораторки, которые делаются уже не одну неделю. Каждый день вы что-то добавляте и вам уже достаточно трудно сориентироваться: что и на каком этапе было добавлено, как называются те или иные устройства. Конечно у вас уже есть копия вашего GIT, и часто приходится прыгать между лабами/конфигами и т.п. И вдруг вам надо добавить на похожие хосты похожие куски конфигов, но вы уже подзапутались какое имя было у того верхнего левого роутера или нижнего правого ACCESS свича...Если знакомая ситуация - читайте дальше, Шура.

Небольшая ремарка: PGP был отжат корпоратами и стал проприетарным, а альтернативная версия с открытым исходным кодом стала носить имя GnuPG (сокр. GPG). Далее в этой статье буду пользоваться аббревиатурой GPG.

Вторая часть истории про слияние репозиториев. Суть проблемы вкратце такова: надо слить репозиторий с подрепозиторием с сохранением истории. Решение на gitpython работало за 6 часов и выдавало удовлетворительный результат. Но, что-то не давало мне покоя...

Гитхаб экшены, как я познавал ci/cd

   Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

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

Меня зовут Руслан, я релиз-инженер в Badoo и Bumble. Недавно я столкнулся с необходимостью оптимизировать механизм автомерджа в мобильных проектах. Задача оказалась интересной, поэтому я решил поделиться её решением с вами. В статье я расскажу, как у нас раньше было реализовано автоматическое слияние веток Git и как потом мы увеличили пропускную способность автомерджа и сохранили надёжность процессов на прежнем высоком уровне.

В этом месяце мы рады представить улучшения в управлении конвейерами и в удобстве использования, призванные повысить продуктивность вашей работы, а также обновления, повышающие безопасность развёртывания, и аналитические данные, которые помогут вам внедрять DevOps на гораздо более высоком уровне. И это — лишь основные из 44 улучшений в этом релизе!

Ребята, всем привет!!!

Выдалась у меня свободная минута и решил я собрать небольшой гайд на прохождение собеседования по направлению программиста 3D графики для GameDev компаний. Сам я работаю в данной сфере и очень много общаюсь с различными людьми, теми кто только приходит собеседования и теми, кто уже трудится достаточно давно и за плечами не один выполненный проект и множество решенных рабочих вопросов и задач. Если вам интересная данная тема, то прошу всех под кат.

Для большинства компаний принято разделять данную профессию/направление на два:

Первые - это специалист игровой графики и Вторые - это специалисты компьютерной графики. В чем же разница? Скажем так, первое является закономерным продолжением второго, но не всегда. Например, вы начинаете работать как VFX специалист, создаете партикловые (частицы) эффекты, "прикручиваете" к ним трехмерные модели, собираете все из частей, пишите шейдера и работаете с кодовой базой. То есть здесь вы больше сконцентрированы на визуальном оформлении игры и отдельных ее элементах. В ваши задачи входит разработка визуальных эффектов на "приемлемом" уровне с учетом общей стилистики игры, ее жанра, цветового оформления (хорор, mathc-3d, ферма, песочница и т.д.). Вопросы оптимизации, здесь важны, но они не так глобальны;

На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):

Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc?

Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.

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

Специально к новому старту курса по разработке на С++ мы решили поделиться переводом статьи Тейлора Блау — разработчика Git, старшего инженера-программиста в Github, о решении проблемы слишком долгой переупаковки репозиториев.

За последние несколько лет я очень полюбил GitLab CI. В основном за его простоту и функциональность. Достаточно просто создать в корне репозитория файл .gitlab-ci.yml , добавить туда несколько строчек кода и при следующем коммите запустится пайплайн с набором джобов, которые будут выполнять указанные команды.

А если добавить к этому возможности include и extends, можно делать достаточно интересные вещи: создавать шаблонные джобы и пайплайны, выносить их в отдельные репозитории и повторно использовать в разных проектах без копирования кода.

Но к сожалению, не всё так радужно, как хотелось бы. Инструкция script в GitLab CI очень низкоуровневая. Она просто выполняет те команды, которые ей переданы в виде строк. Писать большие скрипты внутри YAML не очень удобно. По мере усложнения логики количество скриптов увеличивается, они перемешиваются с YAML делая конфиги нечитаемыми и усложняя их поддержку.

Мне очень не хватало какого-то механизма, который бы упростил разработку больших скриптов. В результате у меня родился микрофреймворк для разработки GitLab CI, про который я и хочу рассказать в этой статье (на примере простого пайплайна для сборки docker-образов).

В прошедший День Земли мы думали о росте. Наши клиенты масштабируют свои DevOps-процессы, и с их ростом возрастает потребность в ещё большей эффективности и автоматизации контроля. GitLab Kubernetes Agent теперь доступен на GitLab.com, что позволит вам воспользоваться преимуществами быстрых развёртываний на вашем кластере благодаря затягиванию изменений из GitLab, в то время как GitLab.com будет управлять необходимыми серверными компонентами агента. Вы сможете настраивать для проверки соответствия требованиям специальные конвейеры (в русской локализации GitLab «сборочные линии»), которые будут в обязательном порядке выполняться для любого проекта с назначенным набором правил, даже для пользовательских наборов. Кроме того, у нас есть множество фич для оценки и повышения эффективности работы конвейеров, для планирования расписания дежурных инженеров, а также улучшения в области безопасности. Вас ждёт более 50 крутых улучшений и новых фич в этом релизе!

С развитием методологии Gitops - имплементации непрерывной поставки при которой описание и изменение системы производятся декларативно с использованием системы контроля версий, а также являющейся естественным продолжением и развитием infrastracture as a code - появляются удобные инструменты для внедрения данного метода. В первую очередь хочется выделить  самые популярные инструменты непрерывной поставки по версии CNCF - ArgoCD и Flux. Оба приложения реализуют схожий функционал - синхронизацию git и кластера kubernetes. Рассмотрим ключевые особенности ArgoCD и как он может обновлять версии образов в git.

• Я держу гит-репозиторий локально у себя на компе
• Все пароли защищены GPG шифрованием, поэтому даже при получении SSH-доступа к моему компьютеру утечка не повлияет на безопасность

Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.