Сложный / оркестрованный CD с AWS CodePipeline или другими

Question

Создание решения без сервера AWS (лямбда, s3, облачная информация и т. Д.) Мне нужно решение для автоматической сборки. Приложение должно храниться в репозитории Git (предпочтительно Bitbucket или Codecommit). Я посмотрел на конвейеры BitBucket, AWS CodePipeline, CodeDeploy, размещенные решения CI / CD, но кажется, что все они делают что-то статичное, как при получении тупого сигнала о том, что что-то изменилось, чтобы перестроить всю среду ... как будто это 1 приложение, не распределенное приложение.

Я хочу определить упорядоченный этапов того, что делать, в зависимости от тип файла на изменение.

например. 1. каждый обновленный .js файл, содержащий лямбда-код, должен сначала использоваться для обновления существующего лямбда-кода 2. после этого, каждый новый или измененный файл / стек облачной информации должен использоваться для обновления или создания существующих, может существовать необходимый порядок (импорт значений друг из друга) 3. после этого код для новых лямбда-файлов в .js-файлах должен использоваться для обновления созданного лямбда-кода (предыдущий шаг).

Не обновленные ресурсы НЕ должны обновляться или пересоздаваться! Похоже, что мои конвейеры должны быть упорядочены И иметь возможность фильтровать входные данные (например, только файлы .js с определенного пути) и получать в качестве входных данных также имя (или названия) измененного (ых) ресурса (ов).

Мне кажется, что я не нахожу эту функциональность в AWS или размещенных git-решениях, таких как BitBucket или CI / CD-конвейеры, таких как CircleCI или Codeship, aws CodePipeline, CodeDeploy и т. Д.

Как получилось? Никому это не нужно? Похоже, основное требование в моих глазах ....

Answer 1

Я снова посмотрел на доступные инструменты AWS и пришел к следующему выводу:

1. При соединении CodePipeline с хранилищем CodeCommit каждый коммит помещает целый пакет хранилища на S3 в качестве входных данных для CodeCommit. Так что не только изменения, но и все.
2. В CodePipeline есть функция оркестровки, которую я искал. Вы можете иметь действия для каждого компонента, такие как create-change-set для компонента SAM, execute-chage-set и т. Д., И можете управлять порядком всех. Но:
   • Поскольку весь код указан в качестве входных данных, я предполагаю, что все действия в CodeCommit будут запущены даже при небольшом изменении кода, которое не затрагивает 99% ресурсов. Подводный SAM или CF сами определят, что изменилось или нет. Но это не очень эффективно. Смотрите мой пост здесь .
   • Я не вижу в обзоре конвейера, какой был запущен в последний раз, и его статус ...
   • Я не могу временно отключить конвейер или триггер с пользовательским вводом

В конце я думаю создать основной конвейер с настраиваемым лямбда-кодом, определяющим, что на самом деле изменилось, с помощью API CodeCommit и разбивающим все действия на под-конвейеры. Из основного конвейера я перенесу их необходимые данные в S3 и выполню их.

Answer 2

(мне не разрешено комментировать, поэтому я постараюсь дать ответ вместо этого - вероятно, не тот, на который вы надеялись :))

Определенно есть необходимость, и в Codeship мы ищем, как лучше поддерживать рабочие процессы FaaS / Serverless. За последние годы это было чем-то вроде движущейся цели, но более распространенные практики и т. Д. Начинают появляться / созревать до такой степени, что имеет смысл начинать их кодификацию.

На данный момент, похоже, что большинство людей, работающих в этом пространстве, прибегают к сценариям (либо безсерверной среде, либо напрямую против поставщиков FaaS), но все борются с проблемой простого развертывания изменений по сравнению с развертыванием всего, на что вы указываете , Сложность с секвенированием еще больше усложняет задачу.

Большинство услуг (включая Codeship) позволят вам в определенной степени использовать последовательный / пошаговый подход к развертыванию, но вам придется проделать всю тяжелую работу по выяснению того, что изменилось и т. Д.

Что касается вашего вопроса, как это происходит? Я думаю, что все зависит только от того, насколько быстро менялись инструменты в последнее время, и от того, как мало кто на самом деле это делает. У крупных компаний есть огромный толчок к переходу на K8, и я думаю, что они в основном только что заглушили последователей FaaS. Не то чтобы это было так, или что мы в Codeship не хотим это менять; это просто, как я лично вижу вещи.