@logickernel/agileflow 0.1.0
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.
- package/README.md +289 -0
- package/bin/agileflow +4 -0
- package/docs/README.md +46 -0
- package/docs/best-practices.md +339 -0
- package/docs/branching-strategy.md +448 -0
- package/docs/cli-reference.md +110 -0
- package/docs/configuration.md +232 -0
- package/docs/conventional-commits/type-build.md +23 -0
- package/docs/conventional-commits/type-chore.md +24 -0
- package/docs/conventional-commits/type-ci.md +23 -0
- package/docs/conventional-commits/type-docs.md +23 -0
- package/docs/conventional-commits/type-feat.md +28 -0
- package/docs/conventional-commits/type-fix.md +27 -0
- package/docs/conventional-commits/type-perf.md +24 -0
- package/docs/conventional-commits/type-refactor.md +24 -0
- package/docs/conventional-commits/type-revert.md +16 -0
- package/docs/conventional-commits/type-style.md +24 -0
- package/docs/conventional-commits/type-test.md +24 -0
- package/docs/conventional-commits.md +234 -0
- package/docs/getting-started.md +209 -0
- package/docs/gitlab-ci-template.md +324 -0
- package/docs/installation.md +163 -0
- package/docs/migration-guide.md +390 -0
- package/docs/release-management.md +498 -0
- package/docs/troubleshooting.md +341 -0
- package/docs/version-centric-cicd.md +166 -0
- package/package.json +39 -0
- package/src/git-utils.js +57 -0
- package/src/index.js +88 -0
- package/src/local.js +17 -0
- package/src/utils.js +376 -0
- package/templates/agileflow-tagged.gitlab-ci.yml +66 -0
- package/templates/agileflow.gitlab-ci.yml +64 -0
|
@@ -0,0 +1,498 @@
|
|
|
1
|
+
# Release Management Guide
|
|
2
|
+
|
|
3
|
+
AgileFlow revolutionizes release management by automating version generation, creating comprehensive release notes, and ensuring consistent deployments across all environments.
|
|
4
|
+
|
|
5
|
+
## Overview
|
|
6
|
+
|
|
7
|
+
Traditional release management often involves:
|
|
8
|
+
- Manual version number management
|
|
9
|
+
- Complex branching strategies for releases
|
|
10
|
+
- Environment-specific deployments
|
|
11
|
+
- Manual release note generation
|
|
12
|
+
- Inconsistent versioning across teams
|
|
13
|
+
|
|
14
|
+
AgileFlow eliminates these challenges by:
|
|
15
|
+
- **Automatic version generation** based on commit history
|
|
16
|
+
- **Single source of truth** for all releases
|
|
17
|
+
- **Version-centric deployments** across all environments
|
|
18
|
+
- **Automated release notes** from conventional commits
|
|
19
|
+
- **Consistent versioning** for all team members
|
|
20
|
+
|
|
21
|
+
## How Version Generation Works
|
|
22
|
+
|
|
23
|
+
### Semantic Versioning
|
|
24
|
+
|
|
25
|
+
AgileFlow follows [Semantic Versioning](https://semver.org/) (SemVer) principles:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
MAJOR.MINOR.PATCH
|
|
29
|
+
^ ^ ^
|
|
30
|
+
| | └── Patch: Bug fixes, documentation, etc.
|
|
31
|
+
| └──────── Minor: New features, backward compatible
|
|
32
|
+
└────────────── Major: Breaking changes
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### Automatic Version Bumping
|
|
36
|
+
|
|
37
|
+
AgileFlow analyzes your commit messages to determine the appropriate version bump:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
# Patch version (v1.0.0 → v1.0.1)
|
|
41
|
+
fix: resolve login validation error
|
|
42
|
+
refactor: improve error handling
|
|
43
|
+
build: update dependencies
|
|
44
|
+
ci: fix pipeline configuration
|
|
45
|
+
perf: optimize database queries
|
|
46
|
+
revert: "feat: add experimental feature"
|
|
47
|
+
|
|
48
|
+
# No version bump
|
|
49
|
+
docs: update API documentation
|
|
50
|
+
chore: update issue templates
|
|
51
|
+
style: fix code formatting
|
|
52
|
+
|
|
53
|
+
# Minor version (v1.0.0 → v1.1.0)
|
|
54
|
+
feat: add user authentication system
|
|
55
|
+
perf: optimize database queries
|
|
56
|
+
feat(api): implement rate limiting
|
|
57
|
+
perf(cache): add Redis caching layer
|
|
58
|
+
|
|
59
|
+
# Major version (v1.0.0 → v2.0.0)
|
|
60
|
+
feat!: remove deprecated API endpoints
|
|
61
|
+
feat(api)!: change user ID format to UUID
|
|
62
|
+
BREAKING CHANGE: modify database schema
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### Version Calculation Logic
|
|
66
|
+
|
|
67
|
+
1. **Analyze commits** since the last version tag
|
|
68
|
+
2. **Identify commit types** using conventional commit format
|
|
69
|
+
3. **Determine bump level** based on highest impact commit
|
|
70
|
+
4. **Generate new version** by incrementing appropriate component
|
|
71
|
+
5. **Create version tag** and push to repository
|
|
72
|
+
|
|
73
|
+
## Release Process
|
|
74
|
+
|
|
75
|
+
### 1. Development Phase
|
|
76
|
+
|
|
77
|
+
During development, team members work on feature branches:
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
# Create feature branch
|
|
81
|
+
git checkout -b feat/user-authentication
|
|
82
|
+
|
|
83
|
+
# Make changes with conventional commits
|
|
84
|
+
git commit -m "feat: implement basic authentication"
|
|
85
|
+
git commit -m "test: add authentication unit tests"
|
|
86
|
+
git commit -m "docs: update authentication API docs"
|
|
87
|
+
|
|
88
|
+
# Push and create merge request
|
|
89
|
+
git push origin feat/user-authentication
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### 2. Merge Request Review
|
|
93
|
+
|
|
94
|
+
Before merging to main:
|
|
95
|
+
|
|
96
|
+
- **Code review** by team members
|
|
97
|
+
- **Automated testing** passes
|
|
98
|
+
- **Documentation** updated
|
|
99
|
+
- **Conventional commits** used consistently
|
|
100
|
+
|
|
101
|
+
### 3. Merge to Main
|
|
102
|
+
|
|
103
|
+
When the merge request is approved and merged:
|
|
104
|
+
|
|
105
|
+
```bash
|
|
106
|
+
# AgileFlow automatically:
|
|
107
|
+
# 1. Detects the merge to main
|
|
108
|
+
# 2. Analyzes commit history
|
|
109
|
+
# 3. Calculates next version
|
|
110
|
+
# 4. Creates version tag
|
|
111
|
+
# 5. Generates release notes
|
|
112
|
+
# 6. Makes VERSION available to CI/CD
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### 4. Automated Release
|
|
116
|
+
|
|
117
|
+
The CI/CD pipeline automatically:
|
|
118
|
+
|
|
119
|
+
```yaml
|
|
120
|
+
# .gitlab-ci.yml
|
|
121
|
+
agileflow:
|
|
122
|
+
stage: version
|
|
123
|
+
# Generates VERSION variable
|
|
124
|
+
|
|
125
|
+
build:
|
|
126
|
+
stage: build
|
|
127
|
+
script:
|
|
128
|
+
- docker build -t myapp:${VERSION} .
|
|
129
|
+
needs:
|
|
130
|
+
- agileflow
|
|
131
|
+
|
|
132
|
+
deploy-staging:
|
|
133
|
+
stage: deploy
|
|
134
|
+
script:
|
|
135
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
136
|
+
environment:
|
|
137
|
+
name: staging
|
|
138
|
+
needs:
|
|
139
|
+
- build
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
## Release Notes Generation
|
|
143
|
+
|
|
144
|
+
### Conventional Commit Release Notes
|
|
145
|
+
|
|
146
|
+
When conventional commits are detected, AgileFlow generates structured release notes:
|
|
147
|
+
|
|
148
|
+
```text
|
|
149
|
+
v1.2.4
|
|
150
|
+
|
|
151
|
+
Features:
|
|
152
|
+
- auth: add OIDC login flow
|
|
153
|
+
- api: implement rate limiting middleware
|
|
154
|
+
- ui: add dark mode toggle
|
|
155
|
+
|
|
156
|
+
Bug fixes:
|
|
157
|
+
- api: correct null handling in user lookup
|
|
158
|
+
- auth: handle expired refresh tokens gracefully
|
|
159
|
+
- ui: fix button alignment in mobile view
|
|
160
|
+
|
|
161
|
+
Performance improvements:
|
|
162
|
+
- cache: implement Redis clustering
|
|
163
|
+
- db: optimize user query performance
|
|
164
|
+
- api: add response compression
|
|
165
|
+
|
|
166
|
+
Documentation:
|
|
167
|
+
- update API authentication guide
|
|
168
|
+
- add deployment troubleshooting section
|
|
169
|
+
- improve contributing guidelines
|
|
170
|
+
|
|
171
|
+
Tests:
|
|
172
|
+
- add integration tests for auth flow
|
|
173
|
+
- increase test coverage to 85%
|
|
174
|
+
- add performance benchmarks
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
### Traditional Commit Release Notes
|
|
178
|
+
|
|
179
|
+
For commits not following conventional format:
|
|
180
|
+
|
|
181
|
+
```text
|
|
182
|
+
v1.2.4
|
|
183
|
+
- Merge branch 'feat/user-authentication'
|
|
184
|
+
- Add user login functionality
|
|
185
|
+
- Fix password validation bug
|
|
186
|
+
- Update documentation
|
|
187
|
+
- Add unit tests
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
## Release Strategies
|
|
191
|
+
|
|
192
|
+
### Continuous Delivery
|
|
193
|
+
|
|
194
|
+
For teams practicing continuous delivery:
|
|
195
|
+
|
|
196
|
+
```yaml
|
|
197
|
+
# .gitlab-ci.yml
|
|
198
|
+
deploy-staging:
|
|
199
|
+
stage: deploy
|
|
200
|
+
script:
|
|
201
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
202
|
+
environment:
|
|
203
|
+
name: staging
|
|
204
|
+
when: always # Deploy every version to staging
|
|
205
|
+
|
|
206
|
+
deploy-production:
|
|
207
|
+
stage: deploy
|
|
208
|
+
script:
|
|
209
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
210
|
+
environment:
|
|
211
|
+
name: production
|
|
212
|
+
when: manual # Manual approval for production
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
### Release Trains
|
|
216
|
+
|
|
217
|
+
For teams using release trains:
|
|
218
|
+
|
|
219
|
+
```yaml
|
|
220
|
+
# .gitlab-ci.yml
|
|
221
|
+
deploy-staging:
|
|
222
|
+
stage: deploy
|
|
223
|
+
script:
|
|
224
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
225
|
+
environment:
|
|
226
|
+
name: staging
|
|
227
|
+
rules:
|
|
228
|
+
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
|
229
|
+
when: never
|
|
230
|
+
- if: '$CI_COMMIT_BRANCH == "main"'
|
|
231
|
+
when: always
|
|
232
|
+
|
|
233
|
+
deploy-production:
|
|
234
|
+
stage: deploy
|
|
235
|
+
script:
|
|
236
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
237
|
+
environment:
|
|
238
|
+
name: production
|
|
239
|
+
rules:
|
|
240
|
+
- if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.0$/' # Only major/minor releases
|
|
241
|
+
when: manual
|
|
242
|
+
```
|
|
243
|
+
|
|
244
|
+
### Feature Flags
|
|
245
|
+
|
|
246
|
+
For teams using feature flags:
|
|
247
|
+
|
|
248
|
+
```yaml
|
|
249
|
+
# .gitlab-ci.yml
|
|
250
|
+
deploy-staging:
|
|
251
|
+
stage: deploy
|
|
252
|
+
script:
|
|
253
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
254
|
+
- ./scripts/update-feature-flags.sh staging
|
|
255
|
+
environment:
|
|
256
|
+
name: staging
|
|
257
|
+
|
|
258
|
+
deploy-production:
|
|
259
|
+
stage: deploy
|
|
260
|
+
script:
|
|
261
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
262
|
+
- ./scripts/update-feature-flags.sh production
|
|
263
|
+
environment:
|
|
264
|
+
name: production
|
|
265
|
+
when: manual
|
|
266
|
+
```
|
|
267
|
+
|
|
268
|
+
## Version Management
|
|
269
|
+
|
|
270
|
+
### Viewing Versions
|
|
271
|
+
|
|
272
|
+
```bash
|
|
273
|
+
# List all versions
|
|
274
|
+
git tag --sort=-version:refname
|
|
275
|
+
|
|
276
|
+
# View specific version
|
|
277
|
+
git show v1.2.3
|
|
278
|
+
|
|
279
|
+
# Compare versions
|
|
280
|
+
git diff v1.2.2..v1.2.3
|
|
281
|
+
|
|
282
|
+
# Checkout specific version
|
|
283
|
+
git checkout v1.2.3
|
|
284
|
+
```
|
|
285
|
+
|
|
286
|
+
### Version Metadata
|
|
287
|
+
|
|
288
|
+
Each version tag contains rich metadata:
|
|
289
|
+
|
|
290
|
+
```bash
|
|
291
|
+
# View tag message (release notes)
|
|
292
|
+
git tag -l -n99 v1.2.3
|
|
293
|
+
|
|
294
|
+
# View tag details
|
|
295
|
+
git show v1.2.3
|
|
296
|
+
|
|
297
|
+
# View commit hash for version
|
|
298
|
+
git rev-list -n 1 v1.2.3
|
|
299
|
+
```
|
|
300
|
+
|
|
301
|
+
### Version History
|
|
302
|
+
|
|
303
|
+
Track version evolution:
|
|
304
|
+
|
|
305
|
+
```bash
|
|
306
|
+
# View version timeline
|
|
307
|
+
git log --oneline --decorate --graph --all
|
|
308
|
+
|
|
309
|
+
# View commits in specific version
|
|
310
|
+
git log v1.2.2..v1.2.3 --oneline
|
|
311
|
+
|
|
312
|
+
# View files changed in version
|
|
313
|
+
git diff --name-only v1.2.2..v1.2.3
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
## Rollback Management
|
|
317
|
+
|
|
318
|
+
### Simple Rollbacks
|
|
319
|
+
|
|
320
|
+
With AgileFlow's version-centric approach, rollbacks are straightforward:
|
|
321
|
+
|
|
322
|
+
```bash
|
|
323
|
+
# Rollback to previous version
|
|
324
|
+
git checkout v1.2.2
|
|
325
|
+
|
|
326
|
+
# Deploy previous version
|
|
327
|
+
kubectl set image deployment/myapp myapp=myapp:v1.2.2
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
### Automated Rollback
|
|
331
|
+
|
|
332
|
+
Implement automated rollback in your CI/CD:
|
|
333
|
+
|
|
334
|
+
```yaml
|
|
335
|
+
# .gitlab-ci.yml
|
|
336
|
+
deploy-production:
|
|
337
|
+
stage: deploy
|
|
338
|
+
script:
|
|
339
|
+
- kubectl set image deployment/myapp myapp=myapp:${VERSION}
|
|
340
|
+
- ./scripts/health-check.sh
|
|
341
|
+
environment:
|
|
342
|
+
name: production
|
|
343
|
+
when: manual
|
|
344
|
+
|
|
345
|
+
rollback-production:
|
|
346
|
+
stage: deploy
|
|
347
|
+
script:
|
|
348
|
+
- PREVIOUS_VERSION=$(git describe --abbrev=0 --tags v${VERSION%.*}.$((10#${VERSION##*.} - 1)))
|
|
349
|
+
- kubectl set image deployment/myapp myapp=myapp:${PREVIOUS_VERSION}
|
|
350
|
+
environment:
|
|
351
|
+
name: production
|
|
352
|
+
when: manual
|
|
353
|
+
allow_failure: true
|
|
354
|
+
```
|
|
355
|
+
|
|
356
|
+
## Release Communication
|
|
357
|
+
|
|
358
|
+
### Release Announcements
|
|
359
|
+
|
|
360
|
+
Automate release announcements:
|
|
361
|
+
|
|
362
|
+
```yaml
|
|
363
|
+
# .gitlab-ci.yml
|
|
364
|
+
announce-release:
|
|
365
|
+
stage: deploy
|
|
366
|
+
script:
|
|
367
|
+
- |
|
|
368
|
+
cat << EOF | curl -X POST -H 'Content-Type: application/json' \
|
|
369
|
+
-d @- $SLACK_WEBHOOK_URL
|
|
370
|
+
{
|
|
371
|
+
"text": "🚀 New Release: ${VERSION}",
|
|
372
|
+
"attachments": [{
|
|
373
|
+
"title": "Release Notes",
|
|
374
|
+
"text": "$(git tag -l -n99 ${VERSION})",
|
|
375
|
+
"color": "good"
|
|
376
|
+
}]
|
|
377
|
+
}
|
|
378
|
+
EOF
|
|
379
|
+
needs:
|
|
380
|
+
- agileflow
|
|
381
|
+
when: manual
|
|
382
|
+
```
|
|
383
|
+
|
|
384
|
+
### Release Documentation
|
|
385
|
+
|
|
386
|
+
Generate release documentation:
|
|
387
|
+
|
|
388
|
+
```yaml
|
|
389
|
+
# .gitlab-ci.yml
|
|
390
|
+
generate-release-docs:
|
|
391
|
+
stage: deploy
|
|
392
|
+
script:
|
|
393
|
+
- mkdir -p releases
|
|
394
|
+
- |
|
|
395
|
+
cat > "releases/${VERSION}.md" << EOF
|
|
396
|
+
# Release ${VERSION}
|
|
397
|
+
|
|
398
|
+
## Changes
|
|
399
|
+
$(git tag -l -n99 ${VERSION})
|
|
400
|
+
|
|
401
|
+
## Deployment
|
|
402
|
+
- Staging: ${CI_ENVIRONMENT_URL}
|
|
403
|
+
- Production: Manual deployment required
|
|
404
|
+
|
|
405
|
+
## Rollback
|
|
406
|
+
Previous version: $(git describe --abbrev=0 --tags v${VERSION%.*}.$((10#${VERSION##*.} - 1)))
|
|
407
|
+
EOF
|
|
408
|
+
- git add releases/
|
|
409
|
+
- git commit -m "docs: add release documentation for ${VERSION}"
|
|
410
|
+
- git push origin main
|
|
411
|
+
needs:
|
|
412
|
+
- agileflow
|
|
413
|
+
```
|
|
414
|
+
|
|
415
|
+
## Best Practices
|
|
416
|
+
|
|
417
|
+
### 1. Consistent Commit Messages
|
|
418
|
+
|
|
419
|
+
```bash
|
|
420
|
+
# ✅ Good - Clear and consistent
|
|
421
|
+
feat(auth): add OAuth2 login support
|
|
422
|
+
fix(api): handle null user ID gracefully
|
|
423
|
+
docs: update installation guide
|
|
424
|
+
|
|
425
|
+
# ❌ Bad - Inconsistent and unclear
|
|
426
|
+
add oauth
|
|
427
|
+
fix bug
|
|
428
|
+
update docs
|
|
429
|
+
```
|
|
430
|
+
|
|
431
|
+
### 2. Small, Focused Releases
|
|
432
|
+
|
|
433
|
+
- **Keep releases small** and focused on specific features
|
|
434
|
+
- **Release frequently** to reduce risk
|
|
435
|
+
- **Test thoroughly** before merging to main
|
|
436
|
+
- **Document breaking changes** clearly
|
|
437
|
+
|
|
438
|
+
### 3. Environment Consistency
|
|
439
|
+
|
|
440
|
+
- **Deploy the same version** to all environments
|
|
441
|
+
- **Use configuration** for environment differences
|
|
442
|
+
- **Test in staging** before production
|
|
443
|
+
- **Monitor deployments** for issues
|
|
444
|
+
|
|
445
|
+
### 4. Version Tagging
|
|
446
|
+
|
|
447
|
+
- **Never manually create** version tags
|
|
448
|
+
- **Let AgileFlow handle** all versioning
|
|
449
|
+
- **Use conventional commits** for automatic versioning
|
|
450
|
+
- **Review release notes** before deployment
|
|
451
|
+
|
|
452
|
+
### 5. Rollback Planning
|
|
453
|
+
|
|
454
|
+
- **Plan rollback procedures** in advance
|
|
455
|
+
- **Test rollback processes** regularly
|
|
456
|
+
- **Document rollback steps** for each environment
|
|
457
|
+
- **Monitor system health** after deployments
|
|
458
|
+
|
|
459
|
+
## Troubleshooting
|
|
460
|
+
|
|
461
|
+
### Common Issues
|
|
462
|
+
|
|
463
|
+
**Version Not Generated**
|
|
464
|
+
- Check that conventional commits are used
|
|
465
|
+
- Verify AgileFlow is properly configured
|
|
466
|
+
- Ensure merge request process is followed
|
|
467
|
+
- Check CI/CD pipeline logs
|
|
468
|
+
|
|
469
|
+
**Release Notes Empty**
|
|
470
|
+
- Verify commit message format
|
|
471
|
+
- Check conventional commit types
|
|
472
|
+
- Ensure commits are properly merged
|
|
473
|
+
- Review AgileFlow configuration
|
|
474
|
+
|
|
475
|
+
**Deployment Issues**
|
|
476
|
+
- Verify VERSION variable is available
|
|
477
|
+
- Check job dependencies in pipeline
|
|
478
|
+
- Ensure environment configuration is correct
|
|
479
|
+
- Review deployment scripts
|
|
480
|
+
|
|
481
|
+
### Getting Help
|
|
482
|
+
|
|
483
|
+
- **Documentation**: Check other guides in this documentation
|
|
484
|
+
- **Examples**: Review the getting started guide
|
|
485
|
+
- **Community**: Join discussions in the community forum
|
|
486
|
+
- **Issues**: Open an issue in the project repository
|
|
487
|
+
|
|
488
|
+
## Conclusion
|
|
489
|
+
|
|
490
|
+
AgileFlow's release management approach transforms complex, manual release processes into automated, consistent workflows. By leveraging conventional commits and version-centric deployments, teams can:
|
|
491
|
+
|
|
492
|
+
- **Automate version generation** and release note creation
|
|
493
|
+
- **Maintain consistency** across all environments
|
|
494
|
+
- **Simplify rollbacks** with version-based deployments
|
|
495
|
+
- **Improve collaboration** with clear release communication
|
|
496
|
+
- **Reduce risk** through frequent, small releases
|
|
497
|
+
|
|
498
|
+
This approach scales from small teams to large enterprises, providing the structure and automation needed for modern software delivery while maintaining the flexibility teams require for effective development.
|