Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все Ваши вопросы.
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все Ваши вопросы.
Наш специалист свяжется с Вами, обсудит оптимальную стратегию сотрудничества, поможет сформировать бизнес требования и рассчитает стоимость услуг.
Наш специалист свяжется с Вами, обсудит оптимальную стратегию сотрудничества, поможет сформировать бизнес требования и рассчитает стоимость услуг.
Заполните онлайн-заявку и получите выгодное спецпредложение прямо сейчас.
За вами будет закреплен персональный менеджер, который расскажет о платформе, ответит на все ваши вопросы и сформирует для вас коммерческое предложение.
Наш специалист свяжется с Вами и
обсудит время собеседования.
1. Регистрация и создание репозитория
Создайте аккаунт. Перейдите на GitLab.com и зарегистрируйтесь, указав адрес электронной почты, имя пользователя и пароль. Подтвердите свою почту.
Создание нового проекта:
— После входа в GitLab нажмите на кнопку «New Project».
— Выберите «Create Blank Project» или «Import Project», если у вас уже есть готовый репозиторий.
— Дайте проекту имя, настройте уровень приватности (Private, Internal, Public) и создайте проект.
2. Установка Git и настройка SSH-ключей
Установка Git: На macOS: brew install git
На Ubuntu/Debian: sudo apt update && sudo apt install git
На Windows: скачайте Git for Windows и установите.
Создание SSH-ключа:
В терминале выполните команду:ssh-keygen -t rsa -b 4096 -C «your_email@example.com»
Скопируйте публичный ключ:cat ~/.ssh/id_rsa.pub
Добавление SSH-ключа в GitLab: Войдите в GitLab и откройте Settings > SSH Keys.
Вставьте ключ в поле Key и нажмите Add Key.
3. Настройка репозитория
Теперь, когда SSH-ключ добавлен, клонируйте репозиторий на свой компьютер.
Клонирование репозитория: На странице вашего проекта скопируйте SSH URL репозитория.
В терминале выполните:git clone git@gitlab.com:username/repo-name.git
Переходите в директорию репозитория:cd repo-name
4. Работа с Git: Основные команды
Создание новой ветки:git checkout -b new-feature
Создание коммита:
Добавьте файлы в индекс:git add.
Зафиксируйте изменения:git commit -m «Добавлен новый функционал»
Отправка изменений на сервер:git push origin new-feature
Создание Merge Request: На странице проекта в GitLab выберите свою ветку и создайте Merge Request.
Опишите изменения и отправьте на ревью.
5. Настройка CI/CD
GitLab предоставляет встроенные инструменты для CI/CD, позволяющие автоматически тестировать и разворачивать код. Начнем с простого конвейера.
Создание .gitlab-ci.yml: В корне проекта создайте файл .gitlab-ci.yml, который будет описывать ваш конвейер.
Пример простого файла:stages:
— build
— test
build_job:
stage: build
script:
— echo «Building the project»
test_job:
stage: test
script:
— echo «Running tests»
Добавление CI/CD в проект:
GitLab автоматически обнаружит .gitlab-ci.yml и запустит описанные процессы после каждого коммита.
6. Полезные советы
Ветки: Создавайте отдельные ветки для каждой фичи или бага. Это упрощает ревью и уменьшает вероятность конфликтов.
Защита веток: В настройках проекта можно настроить Protected Branches, чтобы разрешить коммиты только после ревью.
Pipeline и Jobs: Используйте Pipeline для автоматизации задач, таких как тестирование и деплой.
GitLab — это больше, чем хранилище кода. Это целая платформа, которая объединяет управление проектами, автоматизацию и безопасность в одном месте. Начать работу просто, а возможности GitLab позволяют глубоко интегрировать его в процессы разработки и деплоя. Удачи в работе с GitLab!
Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.
Постмортемы. Это грустное слово означает отчёт или небольшую статью, которую пишут по результатам решения проблемы. С помощью постмортемов SRE-инженер делится важным знанием с командами разработки, помогая избежать ошибок в будущих проектах.
Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.
Чтобы SRE-инженер хорошо знал свой продукт, он часто участвует в его разработке. Как правило, это очень опытный, сильный программист, вожак стаи с самыми мощными лапищами. Иначе команда просто не будет ему доверять.
Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.
В небольших и средних компаниях обычно дежурит один SRE-инженер. Если он пропустит алерт, то решение ситуации придётся откладывать. В больших компаниях инженеров сразу несколько — они могут подстраховать друг друга.
В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.
Предположим, что в пятницу у сервиса два важных события: вечером выходит финальный эпизод сериала «Игры у стола» и тем же вечером разработчики апдейтят бэк. Тесты проходят, всё работает, «Игры» летят — разработчики уходят в бар отмечать долгожданный релиз. А в субботу утром десятки тысяч людей не могут нормально посмотреть сериал: вместо 20 мс сайт работает с задержкой 100500 мс.
При традиционном подходе к надёжности первыми о ситуации узнают сотрудники поддержки, ведь расстроенные зрители заполнят все чаты. Специалист поддержки не может восстановить работу сервиса — он эскалирует проблему, передав её в технический хелп. Там увидят, что случилась большая беда, и начнут вызванивать разработчиков. Не факт, что все они на связи в субботу, ведь у всех нас есть свои дела по выходным. В итоге через несколько часов соберётся консилиум программистов и будет решать, что делать: откатывать апдейт или попытаться пофиксить текущий билд. На восстановление нормальной работоспособности уйдут часы или даже дни — а такой простой очень дорого обходится бизнесу.
Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.
Постмортемы. Это грустное слово означает отчёт или небольшую статью, которую пишут по результатам решения проблемы. С помощью постмортемов SRE-инженер делится важным знанием с командами разработки, помогая избежать ошибок в будущих проектах.
Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.
Чтобы SRE-инженер хорошо знал свой продукт, он часто участвует в его разработке. Как правило, это очень опытный, сильный программист, вожак стаи с самыми мощными лапищами. Иначе команда просто не будет ему доверять.
Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.
В небольших и средних компаниях обычно дежурит один SRE-инженер. Если он пропустит алерт, то решение ситуации придётся откладывать. В больших компаниях инженеров сразу несколько — они могут подстраховать друг друга.
В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.