@logickernel/agileflow 0.2.2 → 0.4.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,498 +1,309 @@
1
- # Release Management Guide
1
+ # Release Management
2
2
 
3
- AgileFlow revolutionizes release management by automating version generation, creating comprehensive release notes, and ensuring consistent deployments across all environments.
3
+ AgileFlow automates version generation with a decoupled architecture that creates version tags, which then trigger your release pipelines.
4
4
 
5
- ## Overview
5
+ ## Architecture
6
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
7
+ ```
8
+ Merge to main ──▶ AgileFlow ──▶ Tag v1.2.3 ──▶ Your build/deploy
9
+ ```
10
+
11
+ 1. **AgileFlow creates the version tag** — Triggered on merge to main
12
+ 2. **Your pipelines handle the release** — Triggered by tag creation
13
+
14
+ This separation keeps versioning independent from build and deployment.
13
15
 
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
16
+ ---
20
17
 
21
18
  ## How Version Generation Works
22
19
 
23
20
  ### Semantic Versioning
24
21
 
25
- AgileFlow follows [Semantic Versioning](https://semver.org/) (SemVer) principles:
22
+ AgileFlow follows [Semantic Versioning](https://semver.org/):
26
23
 
27
24
  ```
28
25
  MAJOR.MINOR.PATCH
29
- ^ ^ ^
30
- | | └── Patch: Bug fixes, documentation, etc.
31
- | └──────── Minor: New features, backward compatible
32
- └────────────── Major: Breaking changes
26
+ └── Bug fixes, refactors
27
+ └──────── New features
28
+ └────────────── Breaking changes
33
29
  ```
34
30
 
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
- ```
31
+ ### Automatic Version Calculation
64
32
 
65
- ### Version Calculation Logic
33
+ | Commit Type | Example | Version Bump |
34
+ |-------------|---------|--------------|
35
+ | Breaking | `feat!: remove API` | Major |
36
+ | Feature | `feat: add login` | Minor |
37
+ | Fix | `fix: resolve crash` | Patch |
38
+ | Performance | `perf: optimize` | Patch |
39
+ | No bump | `docs: update README` | None |
66
40
 
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
41
+ ---
72
42
 
73
43
  ## Release Process
74
44
 
75
- ### 1. Development Phase
45
+ ### 1. Development
76
46
 
77
- During development, team members work on feature branches:
47
+ Work on feature branches:
78
48
 
79
49
  ```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
50
+ git checkout -b feat/user-auth
51
+ git commit -m "feat: implement login flow"
52
+ git push origin feat/user-auth
90
53
  ```
91
54
 
92
- ### 2. Merge Request Review
55
+ ### 2. Merge
93
56
 
94
- Before merging to main:
57
+ Create and merge a pull/merge request to main.
95
58
 
96
- - **Code review** by team members
97
- - **Automated testing** passes
98
- - **Documentation** updated
99
- - **Conventional commits** used consistently
59
+ ### 3. Version Creation (Automatic)
100
60
 
101
- ### 3. Merge to Main
61
+ AgileFlow runs and creates a tag:
62
+ - Analyzes commits since last version
63
+ - Calculates next version
64
+ - Creates annotated tag with release notes
102
65
 
103
- When the merge request is approved and merged:
66
+ ### 4. Release (Your Pipelines)
104
67
 
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
- ```
68
+ Tag creation triggers your release workflow:
69
+ - Build artifacts tagged with version
70
+ - Deploy to environments
71
+ - Run tests
114
72
 
115
- ### 4. Automated Release
73
+ ---
116
74
 
117
- The CI/CD pipeline automatically:
75
+ ## Release Workflows
118
76
 
77
+ ### GitHub Actions
78
+
79
+ **Release workflow** (`.github/workflows/release.yml`):
119
80
  ```yaml
120
- # .gitlab-ci.yml
121
- agileflow:
122
- stage: version
123
- # Generates VERSION variable
81
+ name: Release
82
+ on:
83
+ push:
84
+ tags:
85
+ - 'v*'
86
+
87
+ jobs:
88
+ build:
89
+ runs-on: ubuntu-latest
90
+ steps:
91
+ - uses: actions/checkout@v4
92
+
93
+ - name: Get version
94
+ run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
95
+
96
+ - name: Build
97
+ run: docker build -t myapp:$VERSION .
98
+
99
+ deploy-staging:
100
+ needs: build
101
+ runs-on: ubuntu-latest
102
+ environment: staging
103
+ steps:
104
+ - run: kubectl set image deployment/myapp myapp=myapp:$VERSION
105
+
106
+ deploy-production:
107
+ needs: build
108
+ runs-on: ubuntu-latest
109
+ environment: production
110
+ steps:
111
+ - run: kubectl set image deployment/myapp myapp=myapp:$VERSION
112
+ ```
124
113
 
114
+ ### GitLab CI
115
+
116
+ ```yaml
125
117
  build:
126
118
  stage: build
127
119
  script:
128
- - docker build -t myapp:${VERSION} .
129
- needs:
130
- - agileflow
120
+ - docker build -t myapp:$CI_COMMIT_TAG .
121
+ rules:
122
+ - if: '$CI_COMMIT_TAG =~ /^v/'
131
123
 
132
124
  deploy-staging:
133
125
  stage: deploy
134
126
  script:
135
- - kubectl set image deployment/myapp myapp=myapp:${VERSION}
136
- environment:
137
- name: staging
138
- needs:
139
- - build
140
- ```
127
+ - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
128
+ environment: staging
129
+ rules:
130
+ - if: '$CI_COMMIT_TAG =~ /^v/'
141
131
 
142
- ## Release Notes Generation
132
+ deploy-production:
133
+ stage: deploy
134
+ script:
135
+ - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_TAG
136
+ environment: production
137
+ when: manual
138
+ rules:
139
+ - if: '$CI_COMMIT_TAG =~ /^v/'
140
+ ```
143
141
 
144
- ### Conventional Commit Release Notes
142
+ ---
145
143
 
146
- When conventional commits are detected, AgileFlow generates structured release notes:
144
+ ## Release Notes
147
145
 
148
- ```text
149
- v1.2.4
146
+ AgileFlow generates structured release notes from conventional commits:
150
147
 
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
148
  ```
176
-
177
- ### Traditional Commit Release Notes
178
-
179
- For commits not following conventional format:
180
-
181
- ```text
182
149
  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
150
 
190
- ## Release Strategies
151
+ ### Features
152
+ - auth: add OAuth2 login flow
191
153
 
192
- ### Continuous Delivery
154
+ ### Bug fixes
155
+ - api: handle null user ID
193
156
 
194
- For teams practicing continuous delivery:
157
+ ### Performance
158
+ - cache: implement Redis pooling
159
+ ```
195
160
 
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
161
+ ### View Release Notes
205
162
 
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
163
+ ```bash
164
+ git tag -l -n99 v1.2.4
213
165
  ```
214
166
 
215
- ### Release Trains
167
+ ---
216
168
 
217
- For teams using release trains:
169
+ ## Initial Development (0.x.x)
218
170
 
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
171
+ New projects start at v0.0.0:
232
172
 
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
- ```
173
+ - Features/fixes → Patch bump (0.0.0 → 0.0.1)
174
+ - Breaking changes → Minor bump (0.0.0 → 0.1.0)
243
175
 
244
- ### Feature Flags
176
+ ---
245
177
 
246
- For teams using feature flags:
178
+ ## First Stable Release
247
179
 
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
180
+ Version 1.0.0 represents first stable release. Create manually:
257
181
 
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
182
+ ```bash
183
+ git tag -a v1.0.0 -m "First stable release"
184
+ git push origin v1.0.0
266
185
  ```
267
186
 
268
- ## Version Management
187
+ This will trigger your release workflow.
188
+
189
+ ---
269
190
 
270
- ### Viewing Versions
191
+ ## Viewing Releases
271
192
 
272
193
  ```bash
273
- # List all versions
194
+ # List versions
274
195
  git tag --sort=-version:refname
275
196
 
276
197
  # View specific version
277
198
  git show v1.2.3
278
199
 
279
200
  # Compare versions
280
- git diff v1.2.2..v1.2.3
281
-
282
- # Checkout specific version
283
- git checkout v1.2.3
201
+ git log v1.2.2..v1.2.3 --oneline
284
202
  ```
285
203
 
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
204
+ ---
296
205
 
297
- # View commit hash for version
298
- git rev-list -n 1 v1.2.3
299
- ```
206
+ ## Rollbacks
300
207
 
301
- ### Version History
208
+ ### Simple Rollback
302
209
 
303
- Track version evolution:
210
+ Redeploy a previous version:
304
211
 
305
212
  ```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
213
+ kubectl set image deployment/myapp myapp=myapp:v1.2.2
314
214
  ```
315
215
 
316
- ## Rollback Management
216
+ ### Automated Rollback Job
317
217
 
318
- ### Simple Rollbacks
218
+ **GitHub Actions:**
219
+ ```yaml
220
+ rollback:
221
+ runs-on: ubuntu-latest
222
+ steps:
223
+ - uses: actions/checkout@v4
224
+ with:
225
+ fetch-depth: 0
226
+ - run: |
227
+ PREVIOUS=$(git describe --tags --abbrev=0 HEAD^)
228
+ kubectl set image deployment/myapp myapp=myapp:$PREVIOUS
229
+ ```
319
230
 
320
- With AgileFlow's version-centric approach, rollbacks are straightforward:
231
+ **GitLab CI:**
232
+ ```yaml
233
+ rollback:
234
+ script:
235
+ - PREVIOUS=$(git describe --tags --abbrev=0 HEAD^)
236
+ - kubectl set image deployment/myapp myapp=myapp:$PREVIOUS
237
+ when: manual
238
+ ```
321
239
 
322
- ```bash
323
- # Rollback to previous version
324
- git checkout v1.2.2
240
+ ---
325
241
 
326
- # Deploy previous version
327
- kubectl set image deployment/myapp myapp=myapp:v1.2.2
328
- ```
242
+ ## Release Strategies
329
243
 
330
- ### Automated Rollback
244
+ ### Continuous Delivery
331
245
 
332
- Implement automated rollback in your CI/CD:
246
+ Auto-deploy to staging, manual to production:
333
247
 
334
248
  ```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
249
+ deploy-staging:
250
+ # Runs automatically on tag
344
251
 
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
252
+ deploy-production:
352
253
  when: manual
353
- allow_failure: true
354
254
  ```
355
255
 
356
- ## Release Communication
357
-
358
- ### Release Announcements
256
+ ### Version-Based Gates
359
257
 
360
- Automate release announcements:
258
+ Only deploy certain version types:
361
259
 
362
260
  ```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
261
+ deploy-production:
262
+ rules:
263
+ # Only minor/major versions
264
+ - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.0$/'
382
265
  ```
383
266
 
384
- ### Release Documentation
267
+ ---
385
268
 
386
- Generate release documentation:
269
+ ## Release Communication
270
+
271
+ ### Notifications
387
272
 
388
273
  ```yaml
389
- # .gitlab-ci.yml
390
- generate-release-docs:
391
- stage: deploy
274
+ notify:
392
275
  script:
393
- - mkdir -p releases
394
276
  - |
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
277
+ curl -X POST "$SLACK_WEBHOOK" \
278
+ -d "{\"text\": \"Released $CI_COMMIT_TAG\"}"
279
+ rules:
280
+ - if: '$CI_COMMIT_TAG =~ /^v/'
413
281
  ```
414
282
 
415
- ## Best Practices
416
-
417
- ### 1. Consistent Commit Messages
283
+ ### GitHub Releases
418
284
 
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
285
+ ```yaml
286
+ - uses: softprops/action-gh-release@v1
287
+ with:
288
+ tag_name: ${{ github.ref_name }}
289
+ generate_release_notes: true
429
290
  ```
430
291
 
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
292
+ ---
458
293
 
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
294
+ ## Best Practices
487
295
 
488
- ## Conclusion
296
+ 1. **Use conventional commits** — For accurate versioning
297
+ 2. **Keep releases small** — Easier to debug and rollback
298
+ 3. **Test in staging first** — Before production
299
+ 4. **Document breaking changes** — Clear for users
300
+ 5. **Plan rollbacks** — Have procedures ready
489
301
 
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:
302
+ ---
491
303
 
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
304
+ ## Related Documentation
497
305
 
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.
306
+ - [Getting Started](./getting-started.md) Quick start
307
+ - [Conventional Commits](./conventional-commits.md) — Commit format
308
+ - [Version-Centric CI/CD](./version-centric-cicd.md) — Methodology
309
+ - [Best Practices](./best-practices.md) — Recommendations