@logickernel/agileflow 0.17.0 → 0.17.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,289 +0,0 @@
1
- # Version-Centric CI/CD
2
-
3
- AgileFlow enables a **version-centric approach** to CI/CD where versioning is decoupled from build and deployment. This architecture simplifies pipelines and provides flexibility.
4
-
5
- ## The Decoupled Architecture
6
-
7
- ```
8
- ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
9
- │ Merge to main │ │ Tag: v1.2.3 │ │ Build/Deploy │
10
- │ │ ──────▶ │ │ ──────▶ │ │
11
- │ AgileFlow │ │ (event) │ │ Your pipelines │
12
- │ creates tag │ │ │ │ │
13
- └─────────────────┘ └─────────────────┘ └─────────────────┘
14
- ```
15
-
16
- ### How It Works
17
-
18
- 1. **On merge to main**: AgileFlow analyzes commits and creates a version tag
19
- 2. **Tag creation event**: Triggers your build and deploy pipelines
20
- 3. **Build/Deploy**: Uses the tag as the version identifier
21
-
22
- ### Benefits
23
-
24
- - **Separation of concerns** — Versioning is independent from build/deploy
25
- - **Flexibility** — Any process can hook into tag creation
26
- - **Simplicity** — Each pipeline has one responsibility
27
- - **Reusability** — Same build pipeline for all versions
28
- - **Auditability** — Clear version trail for every deployment
29
-
30
- ---
31
-
32
- ## Traditional vs. Version-Centric
33
-
34
- ### Traditional (Coupled)
35
-
36
- ```yaml
37
- # Everything in one pipeline
38
- on: push to main
39
- → calculate version
40
- → build
41
- → deploy staging
42
- → deploy production
43
- ```
44
-
45
- **Problems:**
46
- - Complex, monolithic pipelines
47
- - Version logic mixed with build logic
48
- - Hard to rerun individual steps
49
-
50
- ### Version-Centric (Decoupled)
51
-
52
- ```yaml
53
- # Pipeline 1: Versioning
54
- on: push to main
55
- → AgileFlow creates tag
56
-
57
- # Pipeline 2: Release
58
- on: tag created
59
- → build with tag version
60
- → deploy staging
61
- → deploy production
62
- ```
63
-
64
- **Benefits:**
65
- - Simple, focused pipelines
66
- - Versioning completely separate
67
- - Easy to rerun builds for any version
68
-
69
- ---
70
-
71
- ## Implementation
72
-
73
- ### GitHub Actions
74
-
75
- **Versioning workflow** (`.github/workflows/version.yml`):
76
- ```yaml
77
- name: Version
78
- on:
79
- push:
80
- branches: [main]
81
-
82
- jobs:
83
- version:
84
- runs-on: ubuntu-latest
85
- steps:
86
- - uses: actions/checkout@v4
87
- with:
88
- fetch-depth: 0
89
-
90
- - uses: actions/setup-node@v4
91
- with:
92
- node-version: '20'
93
-
94
- - name: Create version tag
95
- env:
96
- AGILEFLOW_TOKEN: ${{ secrets.AGILEFLOW_TOKEN }}
97
- run: npx @logickernel/agileflow github
98
- ```
99
-
100
- **Release workflow** (`.github/workflows/release.yml`):
101
- ```yaml
102
- name: Release
103
- on:
104
- push:
105
- tags:
106
- - 'v*'
107
-
108
- jobs:
109
- build:
110
- runs-on: ubuntu-latest
111
- steps:
112
- - uses: actions/checkout@v4
113
-
114
- - name: Get version
115
- run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
116
-
117
- - name: Build
118
- run: docker build -t myapp:$VERSION .
119
-
120
- deploy-staging:
121
- needs: build
122
- runs-on: ubuntu-latest
123
- environment: staging
124
- steps:
125
- - run: kubectl set image deployment/myapp myapp=myapp:$VERSION
126
-
127
- deploy-production:
128
- needs: build
129
- runs-on: ubuntu-latest
130
- environment: production
131
- steps:
132
- - run: kubectl set image deployment/myapp myapp=myapp:$VERSION
133
- ```
134
-
135
- ### GitLab CI
136
-
137
- ```yaml
138
- stages:
139
- - version
140
- - build
141
- - deploy
142
-
143
- # Versioning - runs on merge to main
144
- agileflow:
145
- stage: version
146
- image: node:20-alpine
147
- script:
148
- - npx @logickernel/agileflow gitlab
149
- rules:
150
- - if: '$CI_COMMIT_BRANCH == "main"'
151
-
152
- # Build - runs on tag creation
153
- build:
154
- stage: build
155
- script:
156
- - docker build -t myapp:$CI_COMMIT_TAG .
157
- - docker push myapp:$CI_COMMIT_TAG
158
- rules:
159
- - if: '$CI_COMMIT_TAG =~ /^v/'
160
-
161
- # Deploy - runs on tag creation
162
- deploy-staging:
163
- stage: deploy
164
- script:
165
- - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
166
- environment:
167
- name: staging
168
- rules:
169
- - if: '$CI_COMMIT_TAG =~ /^v/'
170
-
171
- deploy-production:
172
- stage: deploy
173
- script:
174
- - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
175
- environment:
176
- name: production
177
- when: manual
178
- rules:
179
- - if: '$CI_COMMIT_TAG =~ /^v/'
180
- ```
181
-
182
- ---
183
-
184
- ## Version-Centric Deployments
185
-
186
- ### All Environments Use the Same Version
187
-
188
- ```
189
- Tag v1.2.3
190
-
191
- ├──▶ Build: myapp:v1.2.3
192
-
193
- ├──▶ Staging: myapp:v1.2.3
194
-
195
- └──▶ Production: myapp:v1.2.3
196
- ```
197
-
198
- No environment drift — every environment runs identical code.
199
-
200
- ### Simple Rollbacks
201
-
202
- ```bash
203
- # Rollback = deploy previous tag
204
- kubectl set image deployment/myapp myapp=myapp:v1.2.2
205
- ```
206
-
207
- ### Clear Audit Trail
208
-
209
- ```bash
210
- # What version is running?
211
- kubectl get deployment myapp -o jsonpath='{.spec.template.spec.containers[0].image}'
212
- # myapp:v1.2.3
213
-
214
- # What's in that version?
215
- git show v1.2.3
216
- ```
217
-
218
- ---
219
-
220
- ## Advanced Patterns
221
-
222
- ### Conditional Deployments
223
-
224
- Deploy only specific version types:
225
-
226
- ```yaml
227
- # Only deploy minor/major versions to production
228
- deploy-production:
229
- rules:
230
- - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.0$/'
231
- ```
232
-
233
- ### Multiple Services
234
-
235
- Same version for all services in a monorepo:
236
-
237
- ```yaml
238
- build-backend:
239
- script:
240
- - docker build -t backend:$CI_COMMIT_TAG ./backend
241
-
242
- build-frontend:
243
- script:
244
- - docker build -t frontend:$CI_COMMIT_TAG ./frontend
245
- ```
246
-
247
- ### Notifications
248
-
249
- Announce new versions:
250
-
251
- ```yaml
252
- notify:
253
- script:
254
- - |
255
- curl -X POST "$SLACK_WEBHOOK" \
256
- -d "{\"text\": \"Released $CI_COMMIT_TAG\"}"
257
- rules:
258
- - if: '$CI_COMMIT_TAG =~ /^v/'
259
- ```
260
-
261
- ---
262
-
263
- ## Key Advantages
264
-
265
- 1. **Eliminates environment drift** — All environments run identical versions
266
- 2. **Simplifies operations** — Work with versions, not branch states
267
- 3. **Enables easy rollbacks** — Just redeploy a previous tag
268
- 4. **Provides clear audit trail** — Every deployment tied to a version
269
- 5. **Decouples concerns** — Versioning separate from build/deploy
270
-
271
- ---
272
-
273
- ## Migration Path
274
-
275
- If using a traditional coupled approach:
276
-
277
- 1. **Add AgileFlow** — Create versioning workflow
278
- 2. **Add tag-triggered workflow** — For build/deploy
279
- 3. **Test both workflows** — Verify tags trigger releases
280
- 4. **Remove old logic** — Clean up version calculation from build pipeline
281
-
282
- ---
283
-
284
- ## Related Documentation
285
-
286
- - [Getting Started](./getting-started.md) — Quick start
287
- - [Installation Guide](./installation.md) — Setup instructions
288
- - [Branching Strategy](./branching-strategy.md) — Git workflow
289
- - [Best Practices](./best-practices.md) — Recommended patterns