Она использует механизм, известный как OOM Killer (убийца процессов при нехватке памяти), для завершения процессов с целью освобождения памяти. Выбор процесса для завершения базируется на ряде критериев, чтобы минимизировать влияние на работу системы.
Каждому процессу присваиваются очки OOM, которые рассчитываются на основе нескольких факторов, таких как: Объем памяти, используемой процессом. Приоритет процесса. Важность процесса для системы (например, системные демоны имеют более низкие очки).
Основной фактор при расчете очков - это объем потребляемой процессом памяти. Чем больше памяти потребляет процесс, тем выше его OOM Score. Операционная система также учитывает приоритет процесса (nice value) и некоторые другие параметры.
Процесс с наибольшим OOM Score считается наименее критичным для системы и завершается первым.
Процесс A использует 1 ГБ памяти.
Процесс B использует 2 ГБ памяти.
Процесс C использует 500 МБ памяти, но это критический системный процесс.
Процесс A: 300
Процесс B: 600
Процесс C: 100 (низкий, так как процесс критический)
Администраторы могут влиять на работу OOM Killer, настраивая параметры OOM Score для конкретных процессов с помощью файлов в каталоге
/proc
. Например, для изменения приоритета процесса:echo -1000 > /proc/<PID>/oom_score_adj
При срабатывании OOM Killer соответствующие сообщения записываются в системный журнал (обычно
/var/log/syslog
или /var/log/messages
), что позволяет администраторам анализировать причины и предпринимать меры по предотвращению в будущем.Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2
Это инструменты для управления инфраструктурой как кодом (IaC), которые помогают автоматизировать развертывание, управление и масштабирование ресурсов в облачных и локальных средах. Оба инструмента имеют свои сильные и слабые стороны. Выбор между ними зависит от конкретных требований и контекста использования.
Плюсы
Terraform — это один из самых популярных инструментов IaC с большим сообществом и обширной документацией. Множество готовых модулей и примеров, что облегчает начало работы.
Terraform поддерживает широкий спектр облачных провайдеров и сервисов (AWS, Azure, Google Cloud, и т.д.). Разработчики активно добавляют новые провайдеры и обновляют существующие.
Использование HashiCorp Configuration Language (HCL) для написания инфраструктурного кода. Поддержка сложных сценариев развертывания с использованием модулей, переменных и терраформ-рабочих областей.
Минусы
Некоторые функции доступны только в коммерческой версии Terraform Enterprise. Переход на платные функции может быть дорогостоящим для небольших команд.
В некоторых случаях могут возникнуть проблемы с производительностью при управлении очень большими инфраструктурами.
OpenTofu — это форк Terraform, который возник в ответ на изменения в лицензионной политике HashiCorp.
Плюсы
OpenTofu полностью открыт и не требует коммерческих лицензий для использования всех функций. Активное сообщество, которое стремится сохранить инструмент полностью свободным.
OpenTofu сохраняет совместимость с конфигурациями и модулями Terraform, что позволяет легко перейти с Terraform на OpenTofu.
Открытое сообщество разработчиков может быстрее внедрять новые функции и исправления.
Минусы
Хотя OpenTofu быстро растет, его сообщество и экосистема пока меньше, чем у Terraform. Ограниченное количество документации и примеров по сравнению с Terraform.
Хотя OpenTofu совместим с Terraform на текущий момент, в будущем могут возникнуть различия в функциональности и поддержке провайдеров.
Если вам нужна стабильность и зрелость инструмента с широким сообществом и обширной документацией. Если ваша инфраструктура уже использует Terraform и вы не хотите менять инструмент. Если вам нужны коммерческие функции Terraform Enterprise для управления и обеспечения безопасности инфраструктуры.
Если вы хотите использовать полностью открытый инструмент без коммерческих ограничений. Если вас беспокоят изменения в лицензионной политике HashiCorp и вы хотите избежать потенциальных проблем в будущем. Если вы хотите поддержать открытое сообщество и активно участвовать в развитии инструмента.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
В Terraform,
for_each
и count
используются для создания нескольких экземпляров ресурсов на основе списка значений или карты (map). Выбор между ними зависит от структуры данных и конкретного сценария использования.count
используется для создания фиксированного количества экземпляров ресурса на основе числового значения. Это простой способ создания ресурсов, если количество экземпляров известно заранее и не зависит от ключей или других атрибутов.Сценарий: Создание трех экземпляров виртуальных машин с одинаковой конфигурацией.
resource "aws_instance" "example" {
count = 3
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "example-instance-${count.index}"
}
}
for_each
используется для создания ресурсов на основе ключей карты (map) или множества (set). Это позволяет более гибко управлять созданием ресурсов и ссылаться на конкретные экземпляры по их ключам.Сценарий: Создание экземпляров виртуальных машин с разными конфигурациями на основе карты значений.
locals {
instances = {
instance1 = { ami = "ami-0c55b159cbfafe1f0", instance_type = "t2.micro" }
instance2 = { ami = "ami-0c55b159cbfafe1f0", instance_type = "t2.small" }
instance3 = { ami = "ami-0c55b159cbfafe1f0", instance_type = "t2.medium" }
}
}
resource "aws_instance" "example" {
for_each = local.instances
ami = each.value.ami
instance_type = each.value.instance_type
tags = {
Name = each.key
}
}
Если количество экземпляров известно заранее и одинаково для всех экземпляров.
Когда все экземпляры имеют одинаковую конфигурацию или различия минимальны.
Создание трех одинаковых экземпляров S3 бакетов.
resource "aws_s3_bucket" "example" {
count = 3
bucket = "example-bucket-${count.index}"
}
Если количество экземпляров и их конфигурация зависят от динамически определяемых данных.
Когда нужно использовать ключи для идентификации и управления экземплярами ресурсов.
Создание IAM пользователей с различными именами и политиками.
locals {
users = {
alice = "arn:aws:iam::aws:policy/AdministratorAccess"
bob = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}
}
resource "aws_iam_user" "example" {
for_each = local.users
name = each.key
path = "/users/"
}
resource "aws_iam_user_policy_attachment" "example" {
for_each = local.users
user = aws_iam_user.example[each.key].name
policy_arn = each.value
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥3
После создания нового репозитория, будь то локальный или удаленный, необходимо выполнить несколько шагов для начала полноценной работы с ним. Эти шаги включают инициализацию репозитория, настройку удаленного репозитория, добавление файлов, коммит и настройку синхронизации с удаленным репозиторием.
Перейдите на GitHub и войдите в свой аккаунт. Нажмите на кнопку "New" для создания нового репозитория. Введите имя репозитория, описание (опционально), выберите публичный или приватный доступ, инициализируйте с README (если нужно). Нажмите "Create repository".
Если репозиторий уже существует на GitHub
git clone https://github.com/yourusername/your-repository.git
cd your-repository
Если вы создаете новый локальный репозиторий
mkdir your-repository
cd your-repository
git init
Создайте или добавьте файлы
echo "# Your Repository" > README.md
Добавьте файлы в индекс
git add README.md
Сделайте первый коммит
git commit -m "Initial commit"
Если вы инициализировали локальный репозиторий, вам нужно настроить удаленный репозиторий.
git remote add origin https://github.com/yourusername/your-repository.git
Отправьте ваши изменения в удаленный репозиторий
git push -u origin master
Для разработки новых функций или исправлений багов рекомендуется создавать отдельные ветки
git checkout -b feature-branch
После завершения работы в ветке создайте Pull Request на GitHub для обзора и слияния.
Добавьте файл
.gitignore
для исключения ненужных файлов из коммитов. echo "node_modules/" > .gitignore
git add .gitignore
git commit -m "Add .gitignore"
Подключите сервисы Continuous Integration/Continuous Deployment, такие как GitHub Actions, Travis CI или Jenkins, для автоматизации тестирования и развертывания.
# Пример файла .github/workflows/ci.yml для GitHub Actions
name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install
- run: npm test
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2
Redis часто используется вместе с MongoDB по нескольким причинам, связанным с их совместимостью, функциональными возможностями и типами данных, которые они поддерживают. Ниже приведены основные причины, почему эта комбинация предпочтительнее в некоторых сценариях.
MongoDB — это документно-ориентированная база данных, оптимизированная для хранения и управления JSON-подобными документами. Она хорошо подходит для хранения сложных данных и поддерживает гибкую схему.
Redis — это база данных в памяти, которая используется для высокопроизводительного кэширования и обработки данных. Она поддерживает различные структуры данных, такие как строки, списки, множества и хэши. Эти два инструмента дополняют друг друга, предлагая сочетание долговременного хранения данных (MongoDB) и быстрого доступа к данным (Redis).
PostgreSQL — это реляционная база данных с расширенными возможностями, такими как поддержка транзакций, строгая схема и ACID-соответствие. Она хорошо подходит для сложных запросов и аналитики.
Гибкая схема MongoDB позволяет легко изменять структуру данных без сложных миграций. MongoDB отлично работает с JSON-документами, что делает его удобным для хранения полуструктурированных данных.
Redis поддерживает различные структуры данных, такие как списки, множества, сортированные множества и хэши, что делает его идеальным для использования в качестве кэша и обработки данных в реальном времени.
Redis работает в памяти, что обеспечивает очень высокую скорость чтения и записи. Это делает его идеальным для кэширования и временного хранения данных, которые требуют быстрого доступа. Redis может обрабатывать большое количество операций в секунду, что делает его подходящим для высоконагруженных систем.
MongoDB масштабируется горизонтально, что позволяет эффективно управлять большими объемами данных. Поддержка шардинга в MongoDB позволяет распределять данные по нескольким узлам, улучшая производительность и отказоустойчивость.
Redis часто используется для кэширования результатов запросов из MongoDB. Это снижает нагрузку на MongoDB и улучшает производительность системы. Redis может использоваться для хранения сессий пользователей, очередей задач и других временных данных, которые требуют быстрого доступа и обновления.
Использование Redis для кэширования часто запрашиваемых данных из MongoDB. Например, результаты сложных запросов или часто используемые документы могут храниться в Redis для быстрого доступа.
import redis
from pymongo import MongoClient
# Подключение к Redis и MongoDB
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
mongo_client = MongoClient('localhost', 27017)
db = mongo_client['example_db']
collection = db['example_collection']
# Получение данных из Redis
data = redis_client.get('key')
if not data:
# Если данных нет в Redis, получить их из MongoDB
data = collection.find_one({'_id': 'key'})
# Сохранить данные в Redis для кэширования
redis_client.set('key', data)
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Протоколы: TCP (надежная передача данных), UDP (быстрая и ненадёжная), HTTP/HTTPS (веб-протоколы), FTP (передача файлов), SMTP/IMAP/POP3 (почтовые протоколы), WebSocket (двусторонняя связь) и DNS (разрешение имён).
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Это два различных подхода в разработке и доставке программного обеспечения, которые имеют разные цели и методы, но могут взаимодополнять друг друга. Давайте рассмотрим основные различия и связи между ними.
Увеличение гибкости и адаптивности разработки программного обеспечения.
Разработка проходит в коротких циклах (итерациях), что позволяет регулярно представлять работающее программное обеспечение.
Регулярные встречи (например, ежедневные стендапы, спринт-ревью) для получения обратной связи от команды и заинтересованных сторон.
Команды, состоящие из разработчиков, тестировщиков, аналитиков и других специалистов, работают вместе над проектом.
Постоянное взаимодействие с клиентами для уточнения требований и проверки соответствия продукта их ожиданиям.
Фреймворки: Scrum, Kanban, XP (Extreme Programming).
Увеличение скорости и качества доставки программного обеспечения через автоматизацию и улучшение сотрудничества между разработчиками и операционными командами.
Автоматизация сборки, тестирования и развертывания кода, чтобы изменения могли быстро и надежно попасть в рабочую среду.
Использование кода для управления и автоматизации инфраструктуры, что делает процессы повторяемыми и предсказуемыми.
Постоянное отслеживание состояния приложений и инфраструктуры для быстрого обнаружения и устранения проблем.
Улучшение взаимодействия между разработчиками и операционными инженерами через общие инструменты и процессы.
Инструменты: Jenkins, Docker, Kubernetes, Ansible, Terraform, Prometheus, Grafana.
Agile: Сфокусирован на процессе разработки и управлении проектами, улучшая гибкость и адаптивность команды разработки.
DevOps: Сфокусирован на процессе доставки и эксплуатации, улучшая автоматизацию и сотрудничество между разработчиками и операционными командами.
Agile: Включает кросс-функциональные команды, которые работают вместе над созданием программного обеспечения.
DevOps: Включает команды разработчиков и операций, которые совместно работают над автоматизацией и улучшением процессов развертывания и эксплуатации.
Agile: Методы Scrum, Kanban и другие Agile-практики, которые улучшают процесс управления проектами.
DevOps: Инструменты и практики для автоматизации развертывания, мониторинга и управления инфраструктурой.
Помогает улучшить процесс разработки, делая его более гибким и отзывчивым к изменениям.
Дополняет Agile, автоматизируя развертывание и эксплуатацию программного обеспечения, что позволяет быстрее доставлять изменения пользователям.
Может использовать Scrum для управления спринтами и задачами.
Могут быть использованы для автоматизации CI/CD пайплайнов, чтобы каждая итерация разработки могла быть быстро и надежно развернута на серверы.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
Команда
kill
в Linux может отправлять разные сигналы процессам, включая как SIGTERM
, так и SIGKILL
. Основное различие между ними заключается в том, как они обрабатываются процессами.Это сигнал завершения, который может быть перехвачен и обработан процессом. Процесс может выполнить очистку (освободить ресурсы, сохранить состояние и т.д.) перед завершением. По умолчанию команда
kill
отправляет именно этот сигнал. Пример команды: kill <PID>
, где <PID>
- идентификатор процесса.Это сигнал немедленного завершения, который не может быть перехвачен процессом. Процесс завершается мгновенно без выполнения какой-либо очистки. Используется, когда процесс не реагирует на другие сигналы. Пример команды:
kill -9 <PID>
.Когда вы используете команду
kill
без указания сигнала, по умолчанию отправляется сигнал SIGTERM
.kill <PID>
Для отправки сигнала
SIGKILL
используется флаг -9
.kill -9 <PID>
Команда:
kill 1234
Процесс с идентификатором 1234 получит сигнал
SIGTERM
и, если он запрограммирован для обработки этого сигнала, может выполнить завершение с очисткой.Команда:
kill -9 1234
Процесс с идентификатором 1234 будет немедленно завершен без возможности выполнения какой-либо очистки.
Используйте, когда хотите корректно завершить процесс, предоставив ему возможность освободить ресурсы и завершить работу корректно.
Используйте в случае, если процесс не отвечает на
SIGTERM
или находится в зависшем состоянии.Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Anonymous Quiz
73%
Тип службы, доступный только внутри кластера
8%
Инструмент для управления конфигурацией
7%
Система мониторинга сети
12%
Инструмент для автоматического масштабирования
Это функции или объекты, которые обрабатывают определенные события или сигналы. Они позволяют системе или программе реагировать на определенные действия, такие как нажатия кнопок, поступление данных, сигналы от операционной системы и другие события.
В GUI-приложениях хендлеры часто используются для обработки событий, таких как нажатия кнопок, движения мыши или ввод текста.
import tkinter as tk
def on_button_click():
print("Button clicked!")
root = tk.Tk()
button = tk.Button(root, text="Click me", command=on_button_click)
button.pack()
root.mainloop()
В Unix-подобных системах хендлеры могут использоваться для обработки сигналов, таких как
SIGINT
или SIGTERM
. import signal
import time
def signal_handler(sig, frame):
print('Signal received:', sig)
exit(0)
signal.signal(signal.SIGINT, signal_handler)
print('Press Ctrl+C')
while True:
time.sleep(1)
В веб-приложениях хендлеры могут обрабатывать HTTP-запросы.
from flask import Flask
app = Flask(__name__)
@app.route('/')
def home():
return "Hello, World!"
if __name__ == '__main__':
app.run(debug=True)
Хендлеры позволяют отделить логику обработки событий от основной логики приложения, что делает код более структурированным и читаемым.
Хендлеры упрощают управление событиями и реакцией на них, что особенно важно в асинхронных и многозадачных приложениях.
Хендлеры позволяют легко добавлять новые обработчики событий без изменения основной структуры программы.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Это платформа для автоматизации развертывания, масштабирования и управления приложениями в контейнерах. Контейнеры позволяют изолировать приложения и их зависимости, обеспечивая легкую переносимость и консистентность окружения. Основные принципы работы Docker включают в себя контейнеризацию, использование образов, контейнеров, оркестрацию и сетевую инфраструктуру.
Контейнеризация позволяет запускать приложения и их зависимости в изолированных окружениях. Контейнеры предоставляют легкие и эффективные среды, которые включают все необходимое для запуска приложений.
Контейнеры: Легковесные, изолированные окружения, которые работают поверх ядра хостовой операционной системы.
Namespace: Механизм ядра Linux, обеспечивающий изоляцию процессов, сети, PID, пользовательских идентификаторов и монтирования файловых систем.
Cgroups: Контрольные группы в Linux, которые ограничивают и отслеживают использование ресурсов контейнерами, включая процессорное время, память и I/O.
Образы Docker являются шаблонами для создания контейнеров. Образ включает в себя все необходимые компоненты, такие как код приложения, библиотеки, зависимости и конфигурационные файлы.
Dockerfile: Скрипт, содержащий инструкции по созданию образа. Используется для автоматизации создания образов.
Слойность: Каждый образ состоит из нескольких слоев, которые кэшируются и могут использоваться повторно, что ускоряет процесс сборки и уменьшает использование ресурсов.
Docker обеспечивает изоляцию приложений, что позволяет запускать несколько контейнеров на одном хосте без взаимного влияния.
Изоляция процессов: Каждый контейнер имеет свой собственный процессорный контекст, что исключает конфликты между приложениями.
Изоляция файловой системы: Контейнеры имеют свои собственные файловые системы, изолированные от файловой системы хостовой операционной системы.
Безопасность: Docker использует механизмы, такие как AppArmor, SELinux и seccomp, для обеспечения безопасности контейнеров.
Docker предоставляет гибкие возможности управления сетями для контейнеров, включая создание изолированных сетей и подключение контейнеров к различным сетям.
Bridge Network: Создает изолированную сеть для контейнеров на одном хосте.
Host Network: Контейнер использует сетевые интерфейсы хостовой операционной системы.
Overlay Network: Позволяет контейнерам на разных хостах взаимодействовать друг с другом.
Macvlan Network: Контейнеры получают собственные MAC-адреса и ведут себя как физические устройства в сети.
Docker поддерживает различные механизмы хранения данных для обеспечения сохранности и доступности данных контейнеров.
Volumes: Независимые от контейнеров хранилища данных, которые могут быть подключены к одному или нескольким контейнерам.
Bind Mounts: Позволяют монтировать директории хостовой файловой системы в контейнеры.
Tmpfs: Использует память хоста для хранения данных контейнера, что полезно для временных данных.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
Запуск команды
top
на сервере выводит информацию о запущенных процессах, использовании ресурсов и общей загрузке системы. В данном случае, если вы видите надпись elan20
, это скорее всего обозначает имя пользователя или хоста, под которым выполняется процесс или который запустил процесс. Важно уточнить, в каком контексте вы видите эту надпись. Если
elan20
отображается в колонке "USER", это просто означает, что процессы принадлежат пользователю elan20
. Это может быть нормально, если пользователь имеет разрешение выполнять эти процессы.Если
elan20
отображается в колонке "COMMAND", это может быть имя выполняемого процесса или скрипта. Нужно уточнить, что это за процесс и соответствует ли он ожидаемому поведению системы. Возможно, процесс называется так специально для каких-то внутренних нужд.Иногда в заголовках
top
может отображаться имя хоста, к которому вы подключены. Это нормально и просто информирует вас о том, на каком сервере вы находитесь.Проверьте, что за процессы запущены под пользователем
elan20
. Убедитесь, что они не потребляют чрезмерное количество ресурсов и являются допустимыми для данного пользователя.Убедитесь, что пользователь
elan20
не запускает подозрительные или нежелательные процессы.Оцените, как процессы
elan20
влияют на общую производительность системы. Если система перегружена из-за этих процессов, нужно принять меры.top
и посмотрите на колонки USER и COMMANDtop - 15:32:44 up 2:22, 1 user, load average: 0.58, 0.72, 0.61
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 1.1 sy, 0.0 ni, 95.4 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 2052920 total, 532356 free, 1045812 used, 474752 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 732168 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1523 elan20 20 0 142576 7648 5764 S 0.7 0.4 0:02.34 sshd
1524 elan20 20 0 132876 3456 2340 S 0.3 0.2 0:01.87 bash
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4🤔2
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍2
Касается подходов к управлению релизами в системах контроля версий, таких как Git, и их интеграции с процессами CI/CD. Ответ зависит от структуры разработки и процесса релиза в конкретной команде или компании. Однако, в общем, деплой из релизных веток обычно идет на тестовые, стейджинговые или продакшн-окружения. Давайте разберем этот процесс подробнее.
Это ветки, которые создаются на этапе, когда функционал и исправления, готовые к выпуску, отделяются от основной ветки разработки (например,
main
или develop
). Они позволяют:Заморозить текущий набор изменений для подготовки к релизу.
Отделить доработки и исправления релиза от активной разработки.
Упростить процесс тестирования и последующего деплоя.
На тестовое окружение деплой из релизной ветки осуществляется для прохождения проверок качества: Автоматизированное и ручное тестирование.
Проверка производительности, безопасности и других аспектов.
stages:
- test
deploy:
stage: test
script:
- echo "Deploying release branch to QA"
- ./deploy.sh qa
only:
- release/*
После успешного прохождения тестов релизную ветку деплоят в стейджинг. Это окружение максимально похоже на продакшн и используется для финального тестирования: Проверка совместимости с продакшн-системами.
Демонстрация функционала заказчикам или заинтересованным сторонам.
stages:
- staging
deploy:
stage: staging
script:
- echo "Deploying release branch to Staging"
- ./deploy.sh staging
only:
- release/*
После прохождения всех этапов тестирования изменения из релизной ветки деплоятся в продакшн: Обычно это делается автоматически после финального подтверждения.
В некоторых командах финальный мерж релизной ветки в
main
инициирует деплой.stages:
- production
deploy:
stage: production
script:
- echo "Deploying release branch to Production"
- ./deploy.sh production
only:
- release/*
Релизные ветки позволяют избежать включения новых, неподготовленных изменений в текущий релиз.
Если в процессе тестирования или релиза найдены баги, их можно исправить прямо в релизной ветке без влияния на разработку.
Релизные ветки упрощают управление разными стадиями разработки и релиза.
release/1.0.0
от develop
.release/1.0.0
, и изменения деплоятся на стейджинг.main
, и начинается деплой в продакшн.Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1