Мне очень досадно наблюдать, как суровые инженеры, которые программируют микроконтроллеры для самонаводящихся ракет, не могут настроить систему контроля версий, чтобы работать комфортно, эффективно и командно.
Я хочу показать инженерам, как можно без боли контролировать изменения скриптов MATLAB и моделей Simulink, попытаюсь донести матлаберам, не знакомым с системой контроля версий (а таких большинство), что для вас это необходимый инструмент на каждый день.
Мы рады представить вам новый релиз GitLab 14.2 с бета-версией Build Cloud для macOS, предварительным просмотром Markdown, расширенной интеграцией Gitpod, новыми метриками внедрения DevOps и многим другим!
В этой статье я расскажу, как мы организовали последовательное автоматическое увеличение номера версии приложения при выполнении коммита в ветку main с помощью Azure DevOps Pipeline.
Мы делаем этого для того, чтобы все пользователи и разработчики могли видеть, какая именно версия продукта развернута в той или иной среде.
Как перестать создавать Jenkins-джобы руками? Как избежать зависимости от конкретного облачного провайдера? Как Git может помочь не только в разработке, но и в развертывании приложений? Обо всем этом пойдет речь на Luxoft TechFest #5: бесплатном онлайн-мероприятии с тремя докладами по DevOps. Оно пройдет 9 сентября с 18:00 по 20:40.
Под катом — более подробная информация о докладах, а заодно еще и видеозаписи докладов предыдущего Luxoft TechFest (по теме Java и DevOps).
Kubernetes используют так или иначе сейчас примерно все, но и задачи решаются совсем разные. Я расскажу про наши требования и разработанные под них решения для управления множеством кластеров. По теме GitOps не так много статей и обсуждений на Хабре, в отличие от англоязычных источников, поэтому будет интересно и услышать мнение тех, кто применял подход на своей практике.
Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.
Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.
Добрый день, коллеги! Доказывать, что нужно использовать систему контроля версий, уже давно не нужно. И Git занял тут лидирующую позицию, стремительно вытеснив SVN. Но это инструмент, а инструментом нужно уметь пользоваться, чтобы добиться лучших результатов. Как топором, один человек сможет просто срубить дерево а другой из этого дерева сможет сделать великолепную скульптуру. Так и с помощью Git, один человек сможет просто не потерять результаты своего труда за день, а другие смогут организовать совместную работу над проектом нескольких сотен человек. Да так, что о любой строчке кода можно будет и через пять лет сказать, откуда она взялась и для чего нужна.
Постараюсь рассказать для начинающих и не очень разработчиков, как оформлять свои коммиты, чтобы их максимально быстро и без претензий принимали в любые проекты, как опенсорсные так и коммерческие.
Мы рады представить вам релиз GitLab 14.1 с возможностью собирать, публиковать и распространять Helm-чарты, создавать правила эскалации для ответственных за страницу, подключать обработчики заданий GitLab к вашим кластерам Kubernetes, обеспечивать соблюдение решений по покрытию кода и многим другим!
Настройка любой площадки для CMS — это рутинный процесс, который должен быть доведен до автоматизма в каждой уважающей себя компании. А потому частенько воспринимается, как восход солнца — это происходит само собой. На самом деле, нельзя так относиться и надеяться на разработчиков, особенно если часть команды работает на субподряде. Они могут потратить кучу времени и денег проекта на переносах, багах и конфликтах кода.
Задача тимлида — создать команде среду для разработки и правильные условия для написания кода. Меня зовут Артем Первушин, я технический директор в компании Extyl. Чтобы помочь с этим я решил опубликовать напоминалку, основанную на внутренних регламентах нашей компании.
Ревью кода это довольно обыденный процесс. Хотя и не многие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом сообразить пару причин, зачем же делать просматривать код коллег довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.
Я расскажу про причину зачем вам лично может быть полезно ревью кода сокомандников.
Когда-то пару лет назад на работе ко мне обратился коллега (привет!), который знает мою любовь к автоматизации с довольно нетривиальной просьбой. Нужно было почистить старые репозитории в корпоративной орге Github, но не совсем удалить, а сохранить на "всякий случай". Да и не просто сохранить, а сохранить с git историей. Мы с ним довольно быстро набросали скрипт на баше, который принимал аргументом orgName/projectName. После окончания работы скрипта он пушил код в отдельную ветку, и потом можно было это померджить в основную "ветку-хранилище". Скрипт был написан быстро, задачу решал, но все равно оставалось пара действий, которые надо было сделать "руками". Но в том случае это было нормально, так как требовалось подтверждение на архивирование старого проекта. Еще тогда у меня появилась идея сделать Github Actions workflow, с которым я только познакомился. Но свободного времени на это не было. И вот спустя год-полтора я наконец-то сделал задуманное - так появился на свет Bygone project, который доступен на github.
Разберем способ удобного хранения 35 000 файлов домашней коллекции, которая используется на 3 ПК и 2 телефонах. При этом сразу все данные на некоторых устройствах не нужны.
В этой статье мы рассмотрим новый российский сервис от компании ООО "Ресолют" под названием GitFlic, где попробуем найти хорошие моменты, а также выльем весь шквал критики на разработчиков этого чуда...
?. Извечная проблема кодировок. Можно ли что-то сделать?
Когда мы думаем обо всём, что было выпущено за год с момента выхода GitLab 13.0, мы не можем не гордиться нашим сообществом и нашей командой. В этом месяце мы празднуем выход GitLab 14.0, и в связи с этим устроим небольшую ретроспективу. Вместе мы добились такого прогресса за последний год, что нам хочется рассказать обо всём, что потребовалось, чтобы пройти путь до GitLab 14.
Иногда важно не только содержание документации, но и процесс ее подготовки. В некоторых проектах с этим процессом связана львиная доля работы, а его нарушения могут приводить к ошибкам, утрате информации и в конечном итоге к временным и финансовым потерям. И даже если обозначенная тема не является вашей основной задачей, правильная организация этого процесса поможет вам улучшить качество документации и сэкономить время.
Метод, описанный ниже, отличается низким порогом вхождения: фактически уже завтра вы сможете начать работать по-новому.
Итак, у вас есть длинные лабораторки, которые делаются уже не одну неделю. Каждый день вы что-то добавляте и вам уже достаточно трудно сориентироваться: что и на каком этапе было добавлено, как называются те или иные устройства. Конечно у вас уже есть копия вашего GIT, и часто приходится прыгать между лабами/конфигами и т.п. И вдруг вам надо добавить на похожие хосты похожие куски конфигов, но вы уже подзапутались какое имя было у того верхнего левого роутера или нижнего правого ACCESS свича...Если знакомая ситуация - читайте дальше, Шура.
