We at MacPaw practice the approach of service teams. And as one of such teams, the responsibility for delivering software across various environments, from testing to production, falls on our shoulders. In this presentation, I will explain how we are trying to standardize our approach to software delivery in environments with diverse tech stacks and development approaches. The presentation will cover methods such as GitOps, dynamic environments, and event-based software delivery.

2. Rethinking
Continuous
Delivery

3. Hello
there!
Andrii Nasinnyk
Staff Site Reliability
Engineer

4. Хто я?
● Кручу інфраструктуру в MacPaw
● Досвід комерційної розробки
на PHP, NodeJS, Go
● Для душі на Haskell та Rust
Twitter GitHub

5. ● Frontend (SPA, Static)
● Mobile (iOS, Android)
● Desktop
● Backend (Containers)

6. Так де ж цей CD?

7. Що ж у нас?
Kubernetes GitOps/FluxCD
GitHub
Single repo
Multi repo
CI
GitHub Actions
Azure Pipelines
Jenkins

8. Наш типово-нетиповий
пайплайн

9. То як же ми деплоїмо?

10. То що ж з цим не так?
Загальну зміну потрібно зробити у всіх проектах
Потрібно пройти флоу кожної команди
CI процес може бути заблокованим
На деяких проектах може не бути команди
Імперативність

11. А що з безпекою?
Доступ до репозиторію дає доступ до кластеру
Розділення по агентах і ролях – дорого

12. Яка ж альтернатива?
https://github.com/argoproj/argo-cd/issues/3698

13. Але як?
Не залежить від проекту
Не залежить від CI
Не потребує апруву від команди
Зміни можна наслідувати як велюси
між проектами
Декларативно
Доступ з кластера до репозиторія
Інфраструктурна конфігурація окремо
від коду проекту

14. А як код потрапить
в інфраструкту?
Automate image updates to Git

15. А як код потрапить
в інфраструкту?
Automate image updates to Git

16. Наш Flux flow

17. А як бути з динамічними
середовищами?
Не GitOps підхід (Flux for temporary review environments)
Оверхед з декларуванням тимчасових енвів

18. То хто ж нас врятує?
Argo Events
https://github.com/triggermesh/triggermesh/issues/1441
TriggerMesh Tekton Tiggers
https://github.com/tektoncd/triggers/issues/1574

19. Як все ж дізнатись
що і коли розгортати?
Домовленість між Ops та Dev командою.
Наш варіант:

20. Як з цим працювати?

21. Витягуємо дані з евента

22. Створюємо об’єкт

23. Наш flow

24. Demo

25. Що далі?
Повідомляти про стан енву в GitHub
Вирішення проблеми асинхронності через
інший контракт GitHub Deployment
Спосіб продовжити CI при якомусь
фінальному стані CD
https://github.com/anasinnyk/fwdays-demo-2023

26. Q&A

27. Thank you!

29. Хто я
❏ Кручу інфраструктуру в MacPaw
❏ Досвід комерційної розробки на PHP, NodeJS, Go
❏ Для душі на Haskell та Rust
GitHub
Twitter

30. Про що
● Frontend (SPA, Static)
● Mobile (iOS, Android)
● Desktop
● Backend (Containers)

31. Так де ж цей CD?

32. Що ж у нас?
❏ GitHub
❏ Single repo
❏ Multi repo
❏ Kubernetes
❏ GitOps/FluxCD
❏ CI
❏ GitHub Actions
❏ Azure Pipelines
❏ Jenkins

33. Наш типово-нетиповий пайплайн

34. То як же ж ми деплоїмо?

35. То що ж з цим не так?
❏ Загальну зміну потрібно зробити у всіх проектах
❏ Потрібно пройти флоу кожної команди
❏ CI процес може бути заблокованим
❏ На деяких проектах може не бути команди
❏ Імперативність

36. А що з безпекою?
❏ Доступ до репозиторію дає доступ до кластеру
❏ Розділення по агентах і ролях - дорого

37. Яка ж альтернатива?

38. Але як?
Інфраструктурна конфігурація окремо від коду проекту
❏ Не залежить від проекту
❏ Не залежить від CI
❏ Не потребує апруву від команди
❏ Зміни можна наслідувати як велюси між проектами
❏ Декларативно
❏ Доступ з кластера до репозиторія

39. А як код потрапить в інфраструкту?
https://fluxcd.io/flux/guides/image-update/
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
name: cmm-analytic
spec:
image: us-docker.pkg.dev/macpaw/cleanmymac/analytic/server
interval: 1m
provider: gcp
–--
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: cmm-analytic
spec:
imageRepositoryRef:
name: cmm-analytic
filterTags:
pattern: "v.*-rc.*"
policy:
semver:
range: "^0.x-0"

40. А як код потрапить в інфраструкту?
https://fluxcd.io/flux/guides/image-update/
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: projects
spec:
interval: 5m
sourceRef: # reference for GitRepository resource
git:
checkout:
ref:
branch: main
commit:
author:
email: fluxcd@macpaw.com
name: fluxcd
messageTemplate: chore(flux): update images
update:
path: ./flux/projects
strategy: Setters

41. А як бути з динамічними середовищами?
❏ Не GitOps підхід (https://github.com/fluxcd/flux2/discussions/831)
❏ Оверхед з декларуванням тимчасових енвів

42. То хто ж нас врятує?
❏ TriggerMesh
❏ Tekton Tiggers
❏ Argo Events
https://github.com/triggermesh/triggermesh/issues/1441
https://github.com/tektoncd/triggers/issues/1574

43. Як все ж дізнатись що і коли розгортати?
Домовленість між Ops та Dev командою.
Наш варіант:
us-docker.pkg.dev/macpaw/cleanmymac/analytic/server:pr-111.20230901.2
registry / repository / project / component / image : envName . unique id

44. Як з цим працювати?
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
name: ${project}-${component}
spec:
dependencies:
- eventSourceName: gcp-pubsub
transform:
jq: |
.body = {
"registry": ((.body | @base64d | fromjson).tag | split("/")[0]),
"repository": ((.body | @base64d | fromjson).tag | split("/")[1]),
"project": ((.body | @base64d | fromjson).tag | split("/")[2]),
"component": ((.body | @base64d | fromjson).tag | split("/")[3]),
"image": ((.body | @base64d | fromjson).tag | split("/")[-1] | split(":")[0]),
"tag": ((.body | @base64d | fromjson).tag | split("/")[-1] | split(":")[-1]),
"pr": ((.body | @base64d | fromjson).tag | split("/")[-1] | split(":")[-1] |
sub("^pr-(?<n>[0-9]+).*$"; .n ))
}
filters: # filter not needed message
triggers: # tigger kubernetes object created

45. Витягуємо дані з евента
- template:
name: ${project}-${component}-pr
k8s:
operation: patch
source:
resource: # Flux Kustomization here
parameters:
- src: { dependencyName: dep, dataKey: body.pr }
dest: metadata.name
operation: append
- src: { dependencyName: dep, dataKey: body.pr }
dest: spec.postBuild.substitute.pr
- src: { dependencyName: dep, dataKey: body.tag }
dest: GET_FROM_EVENT
- src: { dependencyName: dep, dataKey: body.tag }
dest: spec.postBuild.substitute.latest_tag
parameters:
- src:
dependencyName: dep
dataTemplate: '{{ .Input.body.image | snakecase | printf "spec.postBuild.substitute.%s_tag" }}'
dest: k8s.parameters.2.dest

46. Створюємо об’єкт
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: ${project}-${component}-pr-
namespace: flux-system
spec:
interval: 1m
path: ./flux/projects/${project}/${component}/pr
prune: true
sourceRef:
kind: GitRepository
name: flux-system
namespace: flux-system
postBuild:
substitute:
project: ${project}
component: ${component}
chart_name: ${chart_name:=backend}
chart_version: ${chart_version:=3.0.9}
pr: number

47. Demo

48. Що далі?
❏ Повідомляти про стан енву в GitHub
❏ Вирішення проблеми асинхронності через інший контракт GitHub Deployment
❏ Спосіб продовжити CI при якомусь фінальному стані CD

49. Q&A