Вторая часть истории про слияние репозиториев. Суть проблемы вкратце такова: надо слить репозиторий с подрепозиторием с сохранением истории. Решение на 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.
Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.
GitLab 13.10 уже доступен! В этом месяце мы сосредоточили наше внимание на масштабируемости и удобстве управления продуктом, чтобы вы могли итерировать и вводить новшества быстрее, безопаснее и с меньшим количеством проблем. Релиз 13.10 предлагает улучшения администрирования для масштабирования DevOps в вашей организации, проверку целостности пакетов для аварийного восстановления с Geo, автоматизацию управления уязвимостями для большей эффективности и согласованности в обеспечении безопасности и, как и всегда, множество фантастических вкладов от нашего обширного сообщества. Это — лишь некоторые из более чем 40 новых фич и улучшений в данном релизе.
Работа в оболочке включает в себя выполнение одних и тех же команд снова и снова; что меняется, так это порядок выполнения команд и их параметры. Один из способов упростить рабочий процесс — найти паттерны выполнения команд с аргументами и обернуть их в небольшие скрипты. Такой подход часто оказывается полезным, сильно упрощая работу; другой способ оптимизации рабочего процесса — понять, как добавляются параметры, и попробовать упростить сам ввод. И в преддверии старта нового потока курса Fullstack-разработчик на Python, в этом посте я расскажу о втором подходе.
Данный туториал позволит вам быстро прочувствовать как происходит командная работа с использованием GitLab. В целом, начать практиковать DevOps/CD с GitLab проще чем с использованием других продуктов потому что GitLab — это решение "всё в одном".
В процессе этого туториала мы
Желательны но необязательны базовые знания
Git - одна из самых популярных доступных систем контроля версий, разработанная создателем Linux Линусом Торвальдсом. Она используется как в частных системах, так и на общедоступных веб-сайтах для всех видов разработки. Независимо от того, насколько вы опытны в работе с Git, всегда есть возможности для открытия чего то нового. Вот 5 примеров, которые могут изменить способ работы с этой системой.
Это небольшая заметка о моем форке QGit, о сделанных доработках, и о том, почему эти изменения, с высокой степенью вероятности, не попадут в кодовую базу основного репозитория.
Data-science развивается очень быстро, в том числе благодаря росту объема доступных данных для анализа или построения моделей. Но для создания сложных моделей командам аналитиков нужно работать совместно и эффективно управлять большими датасетами. И вот здесь может помочь, например, DVC — open-source система контроля версий для проектов машинного обучения.
Нашел не так много информации по ней в рунете, поэтому под катом на примере простого ML-проекта расскажу, как работать с инструментом для хранения и обновления датасета.
