Мы движемся к тому, чтобы разделить нашу огромную кодовую линию на меньшие кодовые линии. Но прежде чем сделать это, мне нужно было кое-что узнать об этом.
На данный момент у нас есть одна кодовая линия для одного из проектов, которая развертывает:
- Сетевой стек (VPC, подсети и т. Д.)
- Стек ресурсов (RDS, Redis, DynamoDB, S3 bucket)
- Firehose-With-Transformation-Lambda-Stack (Устанавливает пожарный шланг с преобразованием лямбда, сохраняет данные в S3)
- Лямбда-стек (специфическая бизнес-логика проекта)
- Стек API Gateway (конечные точки, ключи API, сопоставление базовых путей)
- Мониторинг стека (получить метрики из всех ресурсов из предыдущих стеков, а затем представить панель мониторинга)
Кодовая линия запускается codecommit, поэтому всякий раз, когда мы нажимаем изменения кода, запускается конвейер.
Теперь есть несколько основных причин, по которым мы хотим отделить конвейер выше.
- Небольшое изменение в лямбде занимает очень много времени, чтобы пройти через
codepipeline. -> Быстрое решение для обновления лямбда напрямую из
в файле make, чтобы просто обновить лямбда напрямую, но это больше
взломать.
- Некоторые ресурсы, такие как сеть и некоторые базы данных, такие как RDS и DynamoDB, используются несколькими проектами, которые на данный момент
имеют собственную небольшую инфраструктуру.
- Организация меньшего и большего количества кодовых линий позволила бы нам выполнить разделение задач и не проходить их снова и
снова, когда изменения выполняются в другой части
инфраструктура в другом стеке.
На основании приведенной выше информации у меня есть несколько вопросов :
- Каковы плюсы и минусы подхода?
- Как мы можем выполнить запуск одной кодовой линии, когда родительская заканчивается? (В любом случае, использовать CW события?) - Это необходимо в случае, если
что-то изменилось в родительском стеке (в другой кодовой линии)
который включал замену ресурсов, и, следовательно, ценностей
необходимо распространить на дочерний стек (в другом
codepipeline)
Дополнительная информация:
Во время моих исследований - это то, что я обнаружил. Правило событий Cloudwatch, которое может быть вызвано на основании изменения состояния CodePipeline - https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html
Кроме того, архитектор решений AWS отметил, что я могу использовать функции Step для синхронизации CodePipeline, но мне нужно более одного начального состояния для разных CodePipeline.