Привет, Хабр! В блоге 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 за неделю — было чёткое понимание проблематики, подход казался выигрышным решением. Используем полгода.
В этой статье мы рассмотрим, как развернуть собственный GitLab сервер и GitLab Runners с использованием Docker Compose. Это руководство поможет вам создать локальную среду для изучения и практики GitLab CI/CD. Мы пройдем через все этапы: от настройки контейнеров до регистрации раннеров и создания примера CI/CD пайплайна. Независимо от того, новичок вы в CI/CD или опытный разработчик, этот гайд предоставит вам ценные знания для улучшения вашего процесса разработки.
Любой начинающий DevOps начинает своё знакомство с Git. Этот инструмент стал неотъемлемой частью рабочего процесса разработчиков по всему миру. Во многих курсах и руководствах по DevOps описывается настройка серверов через популярные платформы, такие как GitLab, а иногда и Gitea. Однако мне стало интересно попробовать другой путь — использовать встроенный в Git инструмент GitWeb.
Собеседование:
- Какую систему контроля версий используете?
- У нас RTC, но ты привыкнешь.
У всех компаний происходят такие события, как переход на новую версию библиотеки, смена фреймворка, внедрение новых инструментов. Смена системы контроля версий случается не так часто, и застать этот период может быть интересно.
Так получилось, что на новом месте работы использовалась IBM Rational Team Concert или RTC. RTC - разработка компании IBM и является централизованной системой контроля версий. Лицензия на RTC подходила к концу, программисты пускали слюни на git. После обсуждений было принято решение перейти на git. И пока коллеги рассматривали все за и против между использованием rebase и merge команд, я решала написать об опыте перехода с RTC на git .
Хочу сразу уточнить по особенностями организации кода: компонентная архитектура. Компоненты немного упростили нам процесс миграции. Каждый компонент лежит в своём репозитории, которые размещены на одном сервере.
Одним из важным инструментом разработчика, в не зависимости от языка (и религиозных убеждений), является система контроля версий (VCS). И практически промышленным стандартом стала такая распределенная система как GIT. В повседневной работе мы (разработчики, DevOps инженеры, технические писатели и все причастные) используем ее чтобы нести людям добро и свет объединять усилия команд в работе над нашими проектами. И все давно уже выучили «на зубок» основные команды (если не выучили то бегом учить, тут есть отличная книжка) и превратили в рутину то что совсем не давно (олды тут?) казалось гениальным, сложным, а кому то магическим. А современные IDE еще больше нам упростили жизнь, спрятав от нас командную строку и git команды, заменив на возможность кликать мышкой. Но постойте, разве вам в детстве не было интересно понять как та или иная игрушка устроена внутри, как работает холодильник или мотор в папиных жигулях (олды все же тут?)? Так вот и мне стало интересно заглянуть под капот GITу. Конечно как и с любым сложным механизмом уровень этого «заглядывания» под капот может быть разным, кому то будет достаточно увидеть крышку мотора и отверстие куда лить незамерзайку, а кому то «заглянуть под капот» это дойти до марки стали используемой для изготовления той или иной детали жигулей. Поэтому давайте сразу обозначим уровень нашего погружения в этой статье. В статье мы рассмотрим в деталях что происходит когда мы делаем привычные нам «git clone/push», посмотрим как этот процесс устроен и какие есть в нем возможности. Сущности и процессы, которые конечно же останутся за рамками этого повествования, можно будет самостоятельно найти (ссылку я указал выше), ибо охватить такую обширную тему как Git, а тем более его подкапотное пространство, не представляется возможным за раз. Так что все кому интересно прошу под кат.
Часто приходится переключаться между разными операционными системами во время работы. Чтобы не запоминать множество команд, я использую шпаргалку с основными командами, которой решил поделиться с вами.
В ней вы найдете основные команды для работы в терминале Windows, Linux и macOS. Также описаны базовые команды по работе с VirtualEnv и Git.
Привет, меня зовут Дмитрий, и я iOS разработчик в компании Triada. В этой статье я расскажу, как настроить CI/CD для вашего iOS приложения, и приведу пошаговую инструкцию, как сделать это правильно с первого раза – чтобы не пришлось переделывать.
Мы настроим CI/CD для iOS проекта с репозиторием на GitLab с использованием Fastlane. Сборки будем отправлять в Testflight и в Firebase, если он у вас используется.
Мы с радостью объявляем о релизе GitLab 17.0 с каталогом CI/CD в общем доступе, панелью аналитики AI Impact, хостингом обработчиков заданий на Linux Arm, страницами с подробной информацией о развёртывании и многими другими фичами!
Статей на тему что такое git и как им пользоваться на просторах интернета не мало. Я же хочу предложить вам несколько иной взгляд на привычные вещи, а именно, на оформление веток и коммитов, рассмотреть что такое WIP-коммиты, для чего они нужны и как с помощью них можно повысить свою продуктивность и поддерживать чистоту в истории вашего репозитория, в особенности, если вы работаете в команде. Поехали.
Разрабатывая различные приложения, я часто сталкиваюсь с тем, как после очередного коммита, в репозитории я вижу один из важнейших файлов, когда я работаю с переменными окружениями, оказалась на странице репозитория на Github. Речь идет о файле .env, чья общедоступность может быть очень опасным. И для того, чтобы обезопасить хранение конфигурационных переменных и настроек моего приложения, используется данный текстовый файл.
Я работаю на VS Code, и я, to be honest, так и не понял, с какой стати .gitignore "не игнорирует" .env. Причем спокойно "игнорирует" другие файлы, директории.
Всё же, нужно действовать, исходя из конкретного кейса, но если вы не хотите, чтобы какой-нибудь John Doe воспользовался данными из вашего .env, то вы перешли по верной ссылке. Вы же не отдаете ключи грабителю с фразой "Грабьте мой дом", верно?
