Git *

Всем привет! Если вы работаете с Kubernetes, то, скорее всего, используете kubectl, kustomize или Helm для развёртывания сервисов в кластере. Про последнюю утилиту я уже писал статью — можно посмотреть тут. Тогда я рассказал о своём опыте внедрения этого инструмента для собственных нагрузок и сравнил подходы kubectl apply и helm install.

Управление конфигурацией в Kubernetes может осуществляться с помощью различных инструментов. Помимо Helm, можно использовать просто YAML-манифесты или же kustomize. Для каждого из этих инструментов предусмотрена своя команда.

В данной статье мы рассмотрим подход GitOps для K8s-кластеров и применим такой инструмент, как Argo CD.

Всё уже придумано, просто настрой под себя и пользуйся.

Всем привет, я Дмитрий Валеев — DevOps инженер в команде разработки фреймворка для тестирования устройств на заводах Аквариус. И это моя первая маленькая статья на Хабр:)

В любом проекте настаёт день «икс», когда вы понимаете, что необходимо внедрять какое‑либо версионирование. Вот и в нашем случае настал такой момент. Вариант с хэш‑коммитами казался просто хаосом и нужно было привести вид компонент в порядок.

В GitLab CI пайплайны выполняют основную роль в автоматизации процессов CI/CD. Они позволяют разбить весь процесс сборки, тестирования и деплоя на отдельные, логически связанные задачи — или "джобы". Эти джобы структурируются в стадии, каждая из которых представляет собой определенный этап работы — например, сборка, тестирование или развертывание. Такое разделение позволяет ускорить разработку и минимизировать ошибки при доставке кода на продакшн.

В этой статье рассмотрим, как настроить пайплайн с разделением на стадии в GitLab CI.

Мы постоянно используем высокоуровневые команды git, такие как git add и git commit. Однако также существует другая группа команд git, которые обрабатывают низкоуровневые операции.

В этой статье мы создадим git‑коммит, используя низкоуровневые операции, а не команду git commit.

Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab-ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере!

Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.

Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то боятся внедрять даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя. 

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

Я Роман Соловьев, ведущий ИТ‑инженер в отделе RnD и готовых решений Управления развития продукта в СберТехе. Сегодня расскажу о том, как мы синхронизируем Git‑репозитории на двух узлах, какие существуют альтернативы и зачем это вообще нужно.

Расскажу про свой опыт прохождения интенсива в Школе 21 от Сбер.

В нем донесу много того, что поможет тебе принять решение идти или не идти на интесив!

Друзья, приветствую!

Если вы следите за моими статьями, то знаете, что на Хабре у меня опубликовано более 10 объемных публикаций на тему разработки телеграмм ботов через замечательный Python-фреймворк Aiogram 3.

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

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

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

В общем, будет интересно и позновательно!

Привет, Хабр! В блоге beeline cloud я делюсь личным опытом разработки. Ранее рассказывал, как инжектить в статические поля, как упростить себе жизнь при написании тестов, подсвечивал особенности пагинации. А сегодня продолжу знакомить вас с Git, Gitflow и веткой develop. Если вы пропустили первую статью из цикла — рекомендую прочитать тут.

Однажды к нам пришёл клиент с просьбой настроить approve rules для merge request в бесплатной версии GitLab CE. В статье я подробно расскажу, как мы подошли к решению этой задачи, какие проблемы нам пришлось преодолеть и каким образом мы смогли обеспечить соблюдение всех необходимых процессов проверки и апрувов без перехода на платную версию GitLab.

Как найти первую работу в IT? Что нужно знать для этого? На сколько это вообще сложно?

Обо всём по-подробнее здесь.

Привет, Хабр. На связи Михаил, я бэкенд-разработчик в Clevertec. Моя работа связана с проектом, который начинался с создания личного кабинета клиента и развился в экосистему, растущую вместе с бизнесом. На его примере я расскажу, как можно изменять подход к CI/CD, чтобы не тормозить рост проекта и оптимизировать работу команды.

16 июля официальный репозиторий mesa объединил MR о RISC-V, llvmpipe: add a new JIT engine based on LLVM ORCJIT, also add RISC-V support (updated)

Это радует всех пользователей RISC-V. Мы ждали патча больше двух лет, и он наконец-то вышел!

И, почему LLVMpipe ORCJIT важен для RISC-V? Давай я расскажу!

Привет, Хабр! Я Евгений Малышев, SRE-инженер в Купере (так теперь называется СберМаркет). Моя основная задача — это надежная работа сервисов фронтенда, и немалую роль в этом играют правильно построенные пайплайны CI/CD. В этом нам помогает Gitlab CI. В компании мы широко используем этот инструмент для создания общих шаблонов для сервисов на различных языках. На уровне отдельного репозитория легко расширить или настроить шаблонные джобы и добавить свои.

До этого у меня был опыт с Jenkins и Azure Devops, так что Gitlab CI мне показался довольно простым: есть стадии, есть правила запуска джоб с shell-подобным синтаксисом, да и скрипты джоб тоже используют bash-интерпретатор. Но в процессе близкого знакомства не раз возникали ситуации, когда поднимается то одна бровь, то обе, а то и руки в праведном гневе. Заходите посмотреть, какую коллекцию граблей собрал я.

Весь код с примерами граблей можно посмотреть в репозитории.

Статей на тему много, но, видимо, недостаточно. Последние 10 лет в 4-х разных компаниях время от времени слышу от коллег:

— Не могу пошарить экран с кодом, у меня другая ветка сейчас.

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

— Стаскивать ветку для просмотра ПР? Это же неудобно, надо "стэшить" изменения, ветку переключать.

Привет, Хабр! Меня зовут Константин Белкин, я Teamlead SRE в РСХБ‑Интех. Сегодня я расскажу вам про App.Farm — PaaS‑платформу, которую мы самостоятельно разрабатываем и поддерживаем с сентября 2020 года.

Всем привет!

Меня зовут Гребенюк Гузель, я QA-руководитель группы тестирования в АЭРО. Мы занимаемся разработкой eCommerce- и data-решений для крупного бизнеса.

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

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

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

Следующим этапом мы стали формировать e2e цепочки из методов путём получения значений переменных полученных из одного запроса и передачи их в качестве входных параметров в следующий запрос. Это дало толчок к активному использованию вкладки Test в Postman и формированию сниппетов для парсинга ответов и получения нужных значений. В результате мы сформировали шаблоны по базовым тестам, которые стали использовать ручные тестировщики на всех проектах.

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

Кратко: сохраняем лог git в файл и кидаем в браузер тут.

Привет Хабра. Год назад я писал о разных визуализаторах статистики git и своем велосипеде. За это время удалось внести много улучшений, в том числе существенно увеличить набор ачивок для программистов. Но настал творческий тупик и мне уже не хватает фантазии придумывать новые ачивки. Они должны быть смешные, с издевкой и легко переводиться на другие языки. Может у вас будут идеи?

Что такое Docs as Code классно описано в статье Docs as Code: введение в предмет.
В двух словах: это ведение документации на языке разметки (Markdown, AsciiDoc) с хранением в репозитории.
Плюшки — все вытекающие от работы с репозиторием.
Минусы — в этой статье.

На осенних Analyst Days прошлого года добрая четверть докладов была посвящена теме Docs as Code. На тот момент конклав аналитиков на моём прежнем месте работы уже 9 месяцев решал, нужен ли на проекте модный-стильный-молодёжный Docs as Code или всё же остаться в дышащем на ладан Confluence. К чему пришли — не знаю. На новом месте работы мы внедрили Docs as Code за неделю — было чёткое понимание проблематики, подход казался выигрышным решением. Используем полгода.