@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.
- package/README.md +54 -127
- package/docs/guides/github-actions.md +110 -0
- package/docs/guides/gitlab-ci.md +128 -0
- package/docs/guides/other-ci.md +93 -0
- package/docs/index.md +58 -0
- package/docs/reference/cli.md +124 -0
- package/docs/reference/conventional-commits.md +133 -0
- package/docs/start-here/getting-started.md +83 -0
- package/package.json +1 -1
- package/src/git-push.js +2 -4
- package/src/github-push.js +2 -4
- package/src/gitlab-push.js +3 -5
- package/src/index.js +18 -42
- package/docs/README.md +0 -60
- package/docs/best-practices.md +0 -306
- package/docs/branching-strategy.md +0 -347
- package/docs/cli-reference.md +0 -301
- package/docs/configuration.md +0 -217
- package/docs/conventional-commits.md +0 -252
- package/docs/getting-started.md +0 -231
- package/docs/installation.md +0 -300
- package/docs/migration-guide.md +0 -303
- package/docs/release-management.md +0 -309
- package/docs/troubleshooting.md +0 -367
- package/docs/version-centric-cicd.md +0 -289
package/docs/best-practices.md
DELETED
|
@@ -1,306 +0,0 @@
|
|
|
1
|
-
# Best Practices
|
|
2
|
-
|
|
3
|
-
This guide covers recommended practices for using AgileFlow effectively.
|
|
4
|
-
|
|
5
|
-
## Decoupled Pipeline Architecture
|
|
6
|
-
|
|
7
|
-
### Separate Versioning from Build/Deploy
|
|
8
|
-
|
|
9
|
-
AgileFlow works best with a decoupled architecture:
|
|
10
|
-
|
|
11
|
-
```
|
|
12
|
-
Versioning Workflow Release Workflow
|
|
13
|
-
────────────────── ─────────────────
|
|
14
|
-
on: push to main on: tag created
|
|
15
|
-
→ AgileFlow → build
|
|
16
|
-
→ create tag → deploy
|
|
17
|
-
```
|
|
18
|
-
|
|
19
|
-
**Benefits:**
|
|
20
|
-
- Clear separation of concerns
|
|
21
|
-
- Each pipeline has one responsibility
|
|
22
|
-
- Easy to rerun builds independently
|
|
23
|
-
|
|
24
|
-
### Version Workflow (Minimal)
|
|
25
|
-
|
|
26
|
-
Keep the versioning workflow simple:
|
|
27
|
-
|
|
28
|
-
```yaml
|
|
29
|
-
# ✅ Good — Focused on versioning only
|
|
30
|
-
name: Version
|
|
31
|
-
on:
|
|
32
|
-
push:
|
|
33
|
-
branches: [main]
|
|
34
|
-
jobs:
|
|
35
|
-
version:
|
|
36
|
-
steps:
|
|
37
|
-
- uses: actions/checkout@v4
|
|
38
|
-
with:
|
|
39
|
-
fetch-depth: 0
|
|
40
|
-
- run: npx @logickernel/agileflow github
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
### Release Workflow (Complete)
|
|
44
|
-
|
|
45
|
-
Put build and deploy logic in the tag-triggered workflow:
|
|
46
|
-
|
|
47
|
-
```yaml
|
|
48
|
-
# ✅ Good — Triggered by tag, handles build/deploy
|
|
49
|
-
name: Release
|
|
50
|
-
on:
|
|
51
|
-
push:
|
|
52
|
-
tags: ['v*']
|
|
53
|
-
jobs:
|
|
54
|
-
build:
|
|
55
|
-
# Build logic here
|
|
56
|
-
deploy:
|
|
57
|
-
# Deploy logic here
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
---
|
|
61
|
-
|
|
62
|
-
## Commit Message Best Practices
|
|
63
|
-
|
|
64
|
-
### Use Conventional Commits Consistently
|
|
65
|
-
|
|
66
|
-
```bash
|
|
67
|
-
# ✅ Good — Clear type and description
|
|
68
|
-
feat(auth): add OAuth2 login support
|
|
69
|
-
fix(api): handle null user ID gracefully
|
|
70
|
-
|
|
71
|
-
# ❌ Bad — Unclear
|
|
72
|
-
add oauth
|
|
73
|
-
fix bug
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
### Add Scopes for Organization
|
|
77
|
-
|
|
78
|
-
```bash
|
|
79
|
-
# ✅ Good — Scoped commits
|
|
80
|
-
feat(auth): implement JWT validation
|
|
81
|
-
fix(api): resolve timeout issue
|
|
82
|
-
docs(readme): add troubleshooting section
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
### Mark Breaking Changes Properly
|
|
86
|
-
|
|
87
|
-
```bash
|
|
88
|
-
# ✅ Good — Breaking change marked
|
|
89
|
-
feat!: remove deprecated API endpoints
|
|
90
|
-
|
|
91
|
-
# ✅ Good — Using footer
|
|
92
|
-
feat: change API format
|
|
93
|
-
|
|
94
|
-
BREAKING CHANGE: Response uses camelCase keys
|
|
95
|
-
|
|
96
|
-
# ❌ Bad — Not marked
|
|
97
|
-
feat: remove deprecated endpoints
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## Pipeline Best Practices
|
|
103
|
-
|
|
104
|
-
### Use Tag as Version
|
|
105
|
-
|
|
106
|
-
In your release workflow, extract the version from the tag:
|
|
107
|
-
|
|
108
|
-
**GitHub Actions:**
|
|
109
|
-
```yaml
|
|
110
|
-
- name: Get version
|
|
111
|
-
run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
|
|
112
|
-
|
|
113
|
-
- name: Build
|
|
114
|
-
run: docker build -t myapp:$VERSION .
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
**GitLab CI:**
|
|
118
|
-
```yaml
|
|
119
|
-
build:
|
|
120
|
-
script:
|
|
121
|
-
- docker build -t myapp:$CI_COMMIT_TAG .
|
|
122
|
-
rules:
|
|
123
|
-
- if: '$CI_COMMIT_TAG =~ /^v/'
|
|
124
|
-
```
|
|
125
|
-
|
|
126
|
-
### Deploy Same Version Everywhere
|
|
127
|
-
|
|
128
|
-
```yaml
|
|
129
|
-
# ✅ Good — Same version for all environments
|
|
130
|
-
deploy-staging:
|
|
131
|
-
script:
|
|
132
|
-
- kubectl set image deployment/myapp myapp=myapp:$VERSION
|
|
133
|
-
|
|
134
|
-
deploy-production:
|
|
135
|
-
script:
|
|
136
|
-
- kubectl set image deployment/myapp myapp=myapp:$VERSION
|
|
137
|
-
```
|
|
138
|
-
|
|
139
|
-
### Add Health Checks
|
|
140
|
-
|
|
141
|
-
```yaml
|
|
142
|
-
deploy:
|
|
143
|
-
script:
|
|
144
|
-
- kubectl set image deployment/myapp myapp=myapp:$VERSION
|
|
145
|
-
- kubectl rollout status deployment/myapp --timeout=300s
|
|
146
|
-
- ./health-check.sh
|
|
147
|
-
```
|
|
148
|
-
|
|
149
|
-
---
|
|
150
|
-
|
|
151
|
-
## Version Management Best Practices
|
|
152
|
-
|
|
153
|
-
### Keep Releases Small
|
|
154
|
-
|
|
155
|
-
- Small releases reduce risk
|
|
156
|
-
- Frequent releases provide faster feedback
|
|
157
|
-
- Focused changes simplify rollbacks
|
|
158
|
-
|
|
159
|
-
### Test Before Merging
|
|
160
|
-
|
|
161
|
-
- Unit tests pass on feature branches
|
|
162
|
-
- Integration tests run before merge
|
|
163
|
-
- Documentation updated with changes
|
|
164
|
-
|
|
165
|
-
### Plan for Rollbacks
|
|
166
|
-
|
|
167
|
-
**GitHub Actions:**
|
|
168
|
-
```yaml
|
|
169
|
-
rollback:
|
|
170
|
-
runs-on: ubuntu-latest
|
|
171
|
-
steps:
|
|
172
|
-
- uses: actions/checkout@v4
|
|
173
|
-
with:
|
|
174
|
-
fetch-depth: 0
|
|
175
|
-
- name: Rollback
|
|
176
|
-
run: |
|
|
177
|
-
PREVIOUS=$(git describe --tags --abbrev=0 HEAD^)
|
|
178
|
-
kubectl set image deployment/myapp myapp=myapp:$PREVIOUS
|
|
179
|
-
```
|
|
180
|
-
|
|
181
|
-
**GitLab CI:**
|
|
182
|
-
```yaml
|
|
183
|
-
rollback:
|
|
184
|
-
script:
|
|
185
|
-
- PREVIOUS=$(git describe --tags --abbrev=0 HEAD^)
|
|
186
|
-
- kubectl set image deployment/myapp myapp=myapp:$PREVIOUS
|
|
187
|
-
when: manual
|
|
188
|
-
```
|
|
189
|
-
|
|
190
|
-
---
|
|
191
|
-
|
|
192
|
-
## Security Best Practices
|
|
193
|
-
|
|
194
|
-
### Protect Tokens
|
|
195
|
-
|
|
196
|
-
**GitHub:**
|
|
197
|
-
- Use repository secrets (automatically protected)
|
|
198
|
-
- Rotate tokens regularly
|
|
199
|
-
|
|
200
|
-
**GitLab:**
|
|
201
|
-
- Mark variables as Protected and Masked
|
|
202
|
-
- Use project tokens over personal tokens
|
|
203
|
-
|
|
204
|
-
### Minimal Permissions
|
|
205
|
-
|
|
206
|
-
| Platform | Required Permission |
|
|
207
|
-
|----------|---------------------|
|
|
208
|
-
| GitHub | `contents: write` |
|
|
209
|
-
| GitLab | `api` scope, `Maintainer` role |
|
|
210
|
-
|
|
211
|
-
---
|
|
212
|
-
|
|
213
|
-
## Performance Best Practices
|
|
214
|
-
|
|
215
|
-
### Shallow Clone for Release Workflow
|
|
216
|
-
|
|
217
|
-
The release workflow doesn't need full history:
|
|
218
|
-
|
|
219
|
-
```yaml
|
|
220
|
-
# Versioning — needs full history
|
|
221
|
-
version:
|
|
222
|
-
steps:
|
|
223
|
-
- uses: actions/checkout@v4
|
|
224
|
-
with:
|
|
225
|
-
fetch-depth: 0 # Full history
|
|
226
|
-
|
|
227
|
-
# Release — doesn't need history
|
|
228
|
-
build:
|
|
229
|
-
steps:
|
|
230
|
-
- uses: actions/checkout@v4
|
|
231
|
-
# Default shallow clone
|
|
232
|
-
```
|
|
233
|
-
|
|
234
|
-
### Cache Dependencies
|
|
235
|
-
|
|
236
|
-
```yaml
|
|
237
|
-
- uses: actions/cache@v4
|
|
238
|
-
with:
|
|
239
|
-
path: ~/.npm
|
|
240
|
-
key: npm-${{ hashFiles('package-lock.json') }}
|
|
241
|
-
```
|
|
242
|
-
|
|
243
|
-
### Parallel Jobs
|
|
244
|
-
|
|
245
|
-
```yaml
|
|
246
|
-
# Build jobs run in parallel
|
|
247
|
-
build-backend:
|
|
248
|
-
runs-on: ubuntu-latest
|
|
249
|
-
build-frontend:
|
|
250
|
-
runs-on: ubuntu-latest
|
|
251
|
-
```
|
|
252
|
-
|
|
253
|
-
---
|
|
254
|
-
|
|
255
|
-
## Documentation Best Practices
|
|
256
|
-
|
|
257
|
-
### Write Meaningful Commit Messages
|
|
258
|
-
|
|
259
|
-
```bash
|
|
260
|
-
# ✅ Good — Becomes clear release note
|
|
261
|
-
feat(auth): add OAuth2 login with Google and GitHub providers
|
|
262
|
-
|
|
263
|
-
# ❌ Bad — Poor release note
|
|
264
|
-
feat: add login
|
|
265
|
-
```
|
|
266
|
-
|
|
267
|
-
### Include Docs in Changes
|
|
268
|
-
|
|
269
|
-
```bash
|
|
270
|
-
git commit -m "feat(auth): add OAuth2 login
|
|
271
|
-
|
|
272
|
-
- Implement OAuth2 flow
|
|
273
|
-
- Add configuration documentation
|
|
274
|
-
- Update API reference"
|
|
275
|
-
```
|
|
276
|
-
|
|
277
|
-
---
|
|
278
|
-
|
|
279
|
-
## Team Best Practices
|
|
280
|
-
|
|
281
|
-
### Establish Conventions
|
|
282
|
-
|
|
283
|
-
- Document commit message standards
|
|
284
|
-
- Use commit linting (commitlint, husky)
|
|
285
|
-
- Review commit messages in PRs
|
|
286
|
-
|
|
287
|
-
### Communicate Releases
|
|
288
|
-
|
|
289
|
-
```yaml
|
|
290
|
-
notify:
|
|
291
|
-
script:
|
|
292
|
-
- |
|
|
293
|
-
curl -X POST "$SLACK_WEBHOOK" \
|
|
294
|
-
-d "{\"text\": \"Released $VERSION\"}"
|
|
295
|
-
rules:
|
|
296
|
-
- if: '$CI_COMMIT_TAG =~ /^v/'
|
|
297
|
-
```
|
|
298
|
-
|
|
299
|
-
---
|
|
300
|
-
|
|
301
|
-
## Related Documentation
|
|
302
|
-
|
|
303
|
-
- [Getting Started](./getting-started.md) — Quick start
|
|
304
|
-
- [Conventional Commits](./conventional-commits.md) — Commit format
|
|
305
|
-
- [Installation Guide](./installation.md) — Setup
|
|
306
|
-
- [Troubleshooting](./troubleshooting.md) — Common issues
|
|
@@ -1,347 +0,0 @@
|
|
|
1
|
-
# Branching Strategy
|
|
2
|
-
|
|
3
|
-
AgileFlow uses a simplified branching strategy that eliminates complexity while maintaining flexibility.
|
|
4
|
-
|
|
5
|
-
## Overview
|
|
6
|
-
|
|
7
|
-
Unlike traditional Git workflows with multiple long-lived branches, AgileFlow uses:
|
|
8
|
-
|
|
9
|
-
- **Main branch** — Single source of truth for all releases
|
|
10
|
-
- **Feature branches** — Short-lived branches for development
|
|
11
|
-
- **Version tags** — Immutable markers for each release
|
|
12
|
-
|
|
13
|
-
```
|
|
14
|
-
main ─────●─────●─────●─────●───▶
|
|
15
|
-
│ │ │ │
|
|
16
|
-
v v v v
|
|
17
|
-
v1.0.0 v1.0.1 v1.1.0 v1.2.0
|
|
18
|
-
▲ ▲
|
|
19
|
-
│ │
|
|
20
|
-
feat/auth─┘ │
|
|
21
|
-
fix/crash─┘
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
---
|
|
25
|
-
|
|
26
|
-
## Core Principles
|
|
27
|
-
|
|
28
|
-
### 1. Main Branch as Release Source
|
|
29
|
-
|
|
30
|
-
All releases come from main:
|
|
31
|
-
|
|
32
|
-
- **Single version sequence** — v1.0.0, v1.0.1, v1.1.0 all share the same lineage
|
|
33
|
-
- **Consistent history** — Every release builds on the same foundation
|
|
34
|
-
- **Simple rollbacks** — Just deploy a previous version
|
|
35
|
-
- **No branch drift** — All environments run identical code
|
|
36
|
-
|
|
37
|
-
### 2. Short-Lived Development Branches
|
|
38
|
-
|
|
39
|
-
Create focused branches, merge quickly:
|
|
40
|
-
|
|
41
|
-
- **Purpose** — One feature, one fix, or one improvement
|
|
42
|
-
- **Lifespan** — Days to weeks, not months
|
|
43
|
-
- **Target** — Always merge to main
|
|
44
|
-
- **Naming** — Descriptive prefix (feat/, fix/, etc.)
|
|
45
|
-
|
|
46
|
-
### 3. Version-Based Deployments
|
|
47
|
-
|
|
48
|
-
Deploy versions, not branches:
|
|
49
|
-
|
|
50
|
-
```
|
|
51
|
-
Version v1.2.3
|
|
52
|
-
│
|
|
53
|
-
├──▶ Staging
|
|
54
|
-
├──▶ Production
|
|
55
|
-
└──▶ Any environment
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
---
|
|
59
|
-
|
|
60
|
-
## Branch Types
|
|
61
|
-
|
|
62
|
-
### Feature Branches
|
|
63
|
-
|
|
64
|
-
For new functionality:
|
|
65
|
-
|
|
66
|
-
```bash
|
|
67
|
-
git checkout -b feat/user-authentication
|
|
68
|
-
git checkout -b feat/api-rate-limiting
|
|
69
|
-
git checkout -b feat/dark-mode
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
**When to use:**
|
|
73
|
-
- Adding new features
|
|
74
|
-
- Implementing user stories
|
|
75
|
-
- Creating new endpoints
|
|
76
|
-
|
|
77
|
-
**Workflow:**
|
|
78
|
-
1. Create from main
|
|
79
|
-
2. Develop with conventional commits
|
|
80
|
-
3. Open pull/merge request
|
|
81
|
-
4. Merge to main → triggers version bump
|
|
82
|
-
|
|
83
|
-
### Fix Branches
|
|
84
|
-
|
|
85
|
-
For bug fixes:
|
|
86
|
-
|
|
87
|
-
```bash
|
|
88
|
-
git checkout -b fix/login-validation
|
|
89
|
-
git checkout -b fix/api-timeout
|
|
90
|
-
git checkout -b fix/memory-leak
|
|
91
|
-
```
|
|
92
|
-
|
|
93
|
-
**When to use:**
|
|
94
|
-
- Fixing bugs
|
|
95
|
-
- Resolving errors
|
|
96
|
-
- Addressing issues
|
|
97
|
-
|
|
98
|
-
### Hotfix Branches
|
|
99
|
-
|
|
100
|
-
For urgent production fixes:
|
|
101
|
-
|
|
102
|
-
```bash
|
|
103
|
-
git checkout -b hotfix/security-patch
|
|
104
|
-
git checkout -b hotfix/critical-bug
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
**When to use:**
|
|
108
|
-
- Critical production issues
|
|
109
|
-
- Security vulnerabilities
|
|
110
|
-
- Service outages
|
|
111
|
-
|
|
112
|
-
**Workflow:**
|
|
113
|
-
1. Create from main
|
|
114
|
-
2. Implement minimal fix
|
|
115
|
-
3. Fast-track review
|
|
116
|
-
4. Merge and deploy immediately
|
|
117
|
-
|
|
118
|
-
### Refactor Branches
|
|
119
|
-
|
|
120
|
-
For code improvements:
|
|
121
|
-
|
|
122
|
-
```bash
|
|
123
|
-
git checkout -b refactor/auth-service
|
|
124
|
-
git checkout -b refactor/database-layer
|
|
125
|
-
```
|
|
126
|
-
|
|
127
|
-
**When to use:**
|
|
128
|
-
- Improving code structure
|
|
129
|
-
- Reducing technical debt
|
|
130
|
-
- Optimizing performance
|
|
131
|
-
|
|
132
|
-
---
|
|
133
|
-
|
|
134
|
-
## Branch Lifecycle
|
|
135
|
-
|
|
136
|
-
### Create
|
|
137
|
-
|
|
138
|
-
```bash
|
|
139
|
-
# Always start from updated main
|
|
140
|
-
git checkout main
|
|
141
|
-
git pull origin main
|
|
142
|
-
git checkout -b feat/new-feature
|
|
143
|
-
```
|
|
144
|
-
|
|
145
|
-
### Develop
|
|
146
|
-
|
|
147
|
-
```bash
|
|
148
|
-
# Make changes with conventional commits
|
|
149
|
-
git commit -m "feat: implement user login"
|
|
150
|
-
git commit -m "test: add login tests"
|
|
151
|
-
git commit -m "docs: update auth documentation"
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
### Sync
|
|
155
|
-
|
|
156
|
-
```bash
|
|
157
|
-
# Keep up to date with main
|
|
158
|
-
git checkout main
|
|
159
|
-
git pull origin main
|
|
160
|
-
git checkout feat/new-feature
|
|
161
|
-
git rebase main
|
|
162
|
-
```
|
|
163
|
-
|
|
164
|
-
### Complete
|
|
165
|
-
|
|
166
|
-
```bash
|
|
167
|
-
# Push and create pull/merge request
|
|
168
|
-
git push origin feat/new-feature
|
|
169
|
-
```
|
|
170
|
-
|
|
171
|
-
### Cleanup
|
|
172
|
-
|
|
173
|
-
```bash
|
|
174
|
-
# After merge
|
|
175
|
-
git checkout main
|
|
176
|
-
git pull origin main
|
|
177
|
-
git branch -d feat/new-feature
|
|
178
|
-
git push origin --delete feat/new-feature
|
|
179
|
-
```
|
|
180
|
-
|
|
181
|
-
---
|
|
182
|
-
|
|
183
|
-
## Version Management
|
|
184
|
-
|
|
185
|
-
### Automatic Bumping
|
|
186
|
-
|
|
187
|
-
AgileFlow determines version bumps from commits:
|
|
188
|
-
|
|
189
|
-
```bash
|
|
190
|
-
# Patch bump (v1.0.0 → v1.0.1)
|
|
191
|
-
fix: resolve login bug
|
|
192
|
-
|
|
193
|
-
# Minor bump (v1.0.0 → v1.1.0)
|
|
194
|
-
feat: add user dashboard
|
|
195
|
-
|
|
196
|
-
# Major bump (v1.0.0 → v2.0.0)
|
|
197
|
-
feat!: remove deprecated API
|
|
198
|
-
|
|
199
|
-
# No bump
|
|
200
|
-
perf: optimize queries
|
|
201
|
-
refactor: simplify logic
|
|
202
|
-
docs: update README
|
|
203
|
-
chore: update dependencies
|
|
204
|
-
```
|
|
205
|
-
|
|
206
|
-
### Version Tags
|
|
207
|
-
|
|
208
|
-
Every merge to main creates a tag:
|
|
209
|
-
|
|
210
|
-
```bash
|
|
211
|
-
# List versions
|
|
212
|
-
git tag --sort=-version:refname
|
|
213
|
-
|
|
214
|
-
# View version details
|
|
215
|
-
git show v1.2.3
|
|
216
|
-
|
|
217
|
-
# Checkout version
|
|
218
|
-
git checkout v1.2.3
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
---
|
|
222
|
-
|
|
223
|
-
## Environment Management
|
|
224
|
-
|
|
225
|
-
### Configuration Over Branches
|
|
226
|
-
|
|
227
|
-
Use configuration for environment differences, not branches:
|
|
228
|
-
|
|
229
|
-
**GitHub Actions:**
|
|
230
|
-
```yaml
|
|
231
|
-
deploy-staging:
|
|
232
|
-
environment: staging
|
|
233
|
-
env:
|
|
234
|
-
DATABASE_URL: ${{ secrets.STAGING_DB_URL }}
|
|
235
|
-
|
|
236
|
-
deploy-production:
|
|
237
|
-
environment: production
|
|
238
|
-
env:
|
|
239
|
-
DATABASE_URL: ${{ secrets.PROD_DB_URL }}
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
**GitLab CI:**
|
|
243
|
-
```yaml
|
|
244
|
-
deploy-staging:
|
|
245
|
-
environment:
|
|
246
|
-
name: staging
|
|
247
|
-
variables:
|
|
248
|
-
DATABASE_URL: "$STAGING_DB_URL"
|
|
249
|
-
|
|
250
|
-
deploy-production:
|
|
251
|
-
environment:
|
|
252
|
-
name: production
|
|
253
|
-
variables:
|
|
254
|
-
DATABASE_URL: "$PROD_DB_URL"
|
|
255
|
-
```
|
|
256
|
-
|
|
257
|
-
---
|
|
258
|
-
|
|
259
|
-
## Best Practices
|
|
260
|
-
|
|
261
|
-
### Keep Branches Small
|
|
262
|
-
|
|
263
|
-
```bash
|
|
264
|
-
# ✅ Good — Single purpose
|
|
265
|
-
git checkout -b feat/user-login
|
|
266
|
-
git checkout -b fix/password-validation
|
|
267
|
-
|
|
268
|
-
# ❌ Bad — Multiple purposes
|
|
269
|
-
git checkout -b feature-and-bugfixes
|
|
270
|
-
```
|
|
271
|
-
|
|
272
|
-
### Use Conventional Commits
|
|
273
|
-
|
|
274
|
-
```bash
|
|
275
|
-
# ✅ Good — Clear type and scope
|
|
276
|
-
feat(auth): add OAuth2 support
|
|
277
|
-
fix(api): handle null user ID
|
|
278
|
-
|
|
279
|
-
# ❌ Bad — No type
|
|
280
|
-
add oauth login
|
|
281
|
-
fix bug
|
|
282
|
-
```
|
|
283
|
-
|
|
284
|
-
### Rebase Regularly
|
|
285
|
-
|
|
286
|
-
```bash
|
|
287
|
-
# Weekly sync with main
|
|
288
|
-
git checkout main
|
|
289
|
-
git pull
|
|
290
|
-
git checkout your-branch
|
|
291
|
-
git rebase main
|
|
292
|
-
```
|
|
293
|
-
|
|
294
|
-
### Clean Up After Merge
|
|
295
|
-
|
|
296
|
-
```bash
|
|
297
|
-
git branch -d feature-branch
|
|
298
|
-
git push origin --delete feature-branch
|
|
299
|
-
```
|
|
300
|
-
|
|
301
|
-
---
|
|
302
|
-
|
|
303
|
-
## Migration from Other Workflows
|
|
304
|
-
|
|
305
|
-
### From GitFlow
|
|
306
|
-
|
|
307
|
-
1. Stop creating release/develop branches
|
|
308
|
-
2. Use main for all releases
|
|
309
|
-
3. Convert hotfix branches to hotfix/ prefix
|
|
310
|
-
4. Let AgileFlow handle versioning
|
|
311
|
-
|
|
312
|
-
### From GitHub Flow
|
|
313
|
-
|
|
314
|
-
1. Continue using feature branches
|
|
315
|
-
2. Add AgileFlow for versioning
|
|
316
|
-
3. Deploy versions instead of branches
|
|
317
|
-
|
|
318
|
-
### From Trunk-Based Development
|
|
319
|
-
|
|
320
|
-
1. Continue working on main
|
|
321
|
-
2. Use branches for larger changes
|
|
322
|
-
3. Add AgileFlow for versioning
|
|
323
|
-
|
|
324
|
-
---
|
|
325
|
-
|
|
326
|
-
## Troubleshooting
|
|
327
|
-
|
|
328
|
-
### Merge Conflicts
|
|
329
|
-
|
|
330
|
-
- Rebase regularly
|
|
331
|
-
- Keep branches small
|
|
332
|
-
- Resolve during rebase, not merge
|
|
333
|
-
|
|
334
|
-
### Branch Divergence
|
|
335
|
-
|
|
336
|
-
- Always start from updated main
|
|
337
|
-
- Rebase instead of merge
|
|
338
|
-
- Delete branches after merge
|
|
339
|
-
|
|
340
|
-
---
|
|
341
|
-
|
|
342
|
-
## Related Documentation
|
|
343
|
-
|
|
344
|
-
- [Getting Started](./getting-started.md) — Quick start
|
|
345
|
-
- [Conventional Commits](./conventional-commits.md) — Commit format
|
|
346
|
-
- [Version-Centric CI/CD](./version-centric-cicd.md) — Pipeline methodology
|
|
347
|
-
- [Release Management](./release-management.md) — Managing releases
|