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

Выдалась у меня свободная минута и решил я собрать небольшой гайд на прохождение собеседования по направлению программиста 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.

GitLab 13.10 уже доступен! В этом месяце мы сосредоточили наше внимание на масштабируемости и удобстве управления продуктом, чтобы вы могли итерировать и вводить новшества быстрее, безопаснее и с меньшим количеством проблем. Релиз 13.10 предлагает улучшения администрирования для масштабирования DevOps в вашей организации, проверку целостности пакетов для аварийного восстановления с Geo, автоматизацию управления уязвимостями для большей эффективности и согласованности в обеспечении безопасности и, как и всегда, множество фантастических вкладов от нашего обширного сообщества. Это — лишь некоторые из более чем 40 новых фич и улучшений в данном релизе.

Работа в оболочке включает в себя выполнение одних и тех же команд снова и снова; что меняется, так это порядок выполнения команд и их параметры. Один из способов упростить рабочий процесс — найти паттерны выполнения команд с аргументами и обернуть их в небольшие скрипты. Такой подход часто оказывается полезным, сильно упрощая работу; другой способ оптимизации рабочего процесса — понять, как добавляются параметры, и попробовать упростить сам ввод. И в преддверии старта нового потока курса Fullstack-разработчик на Python, в этом посте я расскажу о втором подходе.

Введение в непрерывную поставку (CD) при помощи GitLab

Данный туториал позволит вам быстро прочувствовать как происходит командная работа с использованием GitLab. В целом, начать практиковать DevOps/CD с GitLab проще чем с использованием других продуктов потому что GitLab — это решение "всё в одном".

В процессе этого туториала мы

• настроим базовое управления проектом на GitLab.com;
• создадим конвейер непрерывной поставки
• проведём несколько циклов работы с GitLab Flow
• изучим метрики CI/CD в GitLab

Желательны но необязательны базовые знания

• Git;
• Node.js;
• React;
• Docker;

Git - одна из самых популярных доступных систем контроля версий, разработанная создателем Linux Линусом Торвальдсом. Она используется как в частных системах, так и на общедоступных веб-сайтах для всех видов разработки. Независимо от того, насколько вы опытны в работе с Git, всегда есть возможности для открытия чего то нового. Вот 5 примеров, которые могут изменить способ работы с этой системой.

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

Data-science развивается очень быстро, в том числе благодаря росту объема доступных данных для анализа или построения моделей. Но для создания сложных моделей командам аналитиков нужно работать совместно и эффективно управлять большими датасетами. И вот здесь может помочь, например, DVC — open-source система контроля версий для проектов машинного обучения.

Нашел не так много информации по ней в рунете, поэтому под катом на примере простого ML-проекта расскажу, как работать с инструментом для хранения и обновления датасета.

“Опасное это дело, Фродо, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет.” (с)  Властелин Колец: Братство Кольца

История одного приключения длиною в несколько вечеров в попытке настроить то, что на самом деле занимает 20 минут.

Сегодня почти в каждом проекте существует хотя бы базовая инфраструктура, включающая в себя систему хостинга кода проекта (Github, Bitbucket и др.) и систему его сборки (Teamcity, Jenkins и др.). Мы в ЦФТ активно используем Bitbucket server и Teamcity в наших пайплайнах. Подкатом я расскажу, как мы настроили взаимодействие этих сервисов, с какими трудностями столкнулись и как с ними справились.

Всем привет.

Допустим Вы работаете с Terraform / Terragrunt (второе здесь непринципиально, но лучше изучайте, если ещё не используете) и автоматизируете инфраструктуру, например, в AWS (но совершенно необязательно AWS). Инфраструктура в коде репозитория, разворачивается из него же, казалось бы вот оно GitOps счастье :)

Всё идёт хорошо, пока какой-то пользователь не поменял что-то руками через консоль / UI и конечно забыл об этом кому-либо сказать. А то и сделал что-то нехорошее намеренно. И вот он ваш дрейф: код и инфраструктура больше не совпадают!

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