Refactor documentation standards and structure; consolidate clean code principles and service documentation requirements
This commit is contained in:
glenn schrooyen
@@ -6,26 +6,30 @@ alwaysApply: false
|
||||
|
||||
# API Standards
|
||||
|
||||
## API Documentation
|
||||
When working with service files, follow these standards:
|
||||
|
||||
### OpenAPI Requirements
|
||||
## Service Documentation
|
||||
Each service MUST have comprehensive documentation:
|
||||
- **API Gateway**: @services/api-gateway/README.md and @services/api-gateway/CLEAN_CODE.md
|
||||
- **Service Adapters**: @services/service-adapters/README.md and @services/service-adapters/CLEAN_CODE.md
|
||||
- **API Docs**: @services/api-docs/README.md and @services/api-docs/CLEAN_CODE.md
|
||||
|
||||
## Clean Code Implementation
|
||||
Apply the principles detailed in each service's CLEAN_CODE.md:
|
||||
- **Java Spring Boot**: Follow @services/api-gateway/CLEAN_CODE.md
|
||||
- **Python FastAPI**: Follow @services/service-adapters/CLEAN_CODE.md
|
||||
- **Node.js Express**: Follow @services/api-docs/CLEAN_CODE.md
|
||||
|
||||
## API Documentation
|
||||
- All endpoints MUST have OpenAPI documentation
|
||||
- Include request/response schemas
|
||||
- Provide example requests and responses
|
||||
- Document error responses
|
||||
- Include authentication requirements
|
||||
|
||||
### Documentation Tags
|
||||
- Use consistent tags for endpoint grouping
|
||||
- Provide clear descriptions
|
||||
- Include parameter documentation
|
||||
- Document response codes
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Consistent Error Responses
|
||||
Use consistent error response format:
|
||||
```javascript
|
||||
// Standard error response format
|
||||
{
|
||||
"error": "Error type",
|
||||
"message": "User-friendly message",
|
||||
@@ -34,63 +38,24 @@ alwaysApply: false
|
||||
}
|
||||
```
|
||||
|
||||
### HTTP Status Codes
|
||||
- 200: Success
|
||||
- 201: Created
|
||||
- 400: Bad Request
|
||||
- 401: Unauthorized
|
||||
- 403: Forbidden
|
||||
- 404: Not Found
|
||||
- 500: Internal Server Error
|
||||
- 503: Service Unavailable
|
||||
## HTTP Status Codes
|
||||
- 200: Success, 201: Created
|
||||
- 400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found
|
||||
- 500: Internal Server Error, 503: Service Unavailable
|
||||
|
||||
## Service-Specific Standards
|
||||
|
||||
### Java Spring Boot
|
||||
- Use constructor injection
|
||||
- Implement proper validation
|
||||
- Use appropriate annotations
|
||||
- Follow REST conventions
|
||||
- Implement global exception handling
|
||||
|
||||
### Python FastAPI
|
||||
- Use Pydantic models
|
||||
- Implement async/await
|
||||
- Use dependency injection
|
||||
- Follow OpenAPI standards
|
||||
- Implement proper error handling
|
||||
|
||||
### Node.js Express
|
||||
- Use middleware appropriately
|
||||
- Implement proper error handling
|
||||
- Use async/await patterns
|
||||
- Follow REST conventions
|
||||
- Implement health checks
|
||||
- **Java Spring Boot**: Constructor injection, proper validation, REST conventions
|
||||
- **Python FastAPI**: Pydantic models, async/await, dependency injection
|
||||
- **Node.js Express**: Middleware usage, error handling, health checks
|
||||
|
||||
## Validation
|
||||
|
||||
### Input Validation
|
||||
- Validate all inputs
|
||||
- Sanitize user data
|
||||
- Use appropriate data types
|
||||
- Implement rate limiting
|
||||
|
||||
### Response Validation
|
||||
- Validate response schemas
|
||||
- Use consistent data formats
|
||||
- Implement proper error handling
|
||||
- Document response structures
|
||||
|
||||
## Performance
|
||||
|
||||
### API Performance
|
||||
- Use pagination for large datasets
|
||||
- Implement response compression
|
||||
- Use appropriate HTTP methods
|
||||
- Optimize response sizes
|
||||
|
||||
### Caching
|
||||
- Implement appropriate caching
|
||||
- Use Redis for distributed caching
|
||||
- Cache frequently accessed data
|
||||
- Implement cache invalidation
|
||||
- Optimize response sizes
|
||||
@@ -6,69 +6,41 @@ alwaysApply: true
|
||||
|
||||
# Code Quality Standards
|
||||
|
||||
When working with code files, follow these standards:
|
||||
|
||||
## Clean Code Documentation
|
||||
Apply the principles detailed in the comprehensive clean code guides:
|
||||
- **Project Overview**: @CLEAN_CODE.md
|
||||
- **API Gateway**: @services/api-gateway/CLEAN_CODE.md
|
||||
- **Service Adapters**: @services/service-adapters/CLEAN_CODE.md
|
||||
- **API Docs**: @services/api-docs/CLEAN_CODE.md
|
||||
- **Frontend**: @frontend/CLEAN_CODE.md
|
||||
|
||||
## Clean Code Principles
|
||||
|
||||
### Single Responsibility Principle (SRP)
|
||||
- Each class/component has one clear purpose
|
||||
- Each function/method does one thing
|
||||
- Clear separation of concerns
|
||||
- Minimal coupling between components
|
||||
|
||||
### Open/Closed Principle (OCP)
|
||||
- Open for extension, closed for modification
|
||||
- Use interfaces and abstractions
|
||||
- Plugin architecture where appropriate
|
||||
- Configuration-driven behavior
|
||||
|
||||
### Dependency Inversion Principle (DIP)
|
||||
- Depend on abstractions, not concretions
|
||||
- Use dependency injection
|
||||
- Interface-based design
|
||||
- Inversion of control
|
||||
|
||||
### Interface Segregation Principle (ISP)
|
||||
- Small, focused interfaces
|
||||
- Clients should not depend on unused methods
|
||||
- Specific-purpose modules
|
||||
- Clear API boundaries
|
||||
Follow SOLID principles as detailed in @CLEAN_CODE.md:
|
||||
- **Single Responsibility Principle (SRP)**: Each class/component has one clear purpose
|
||||
- **Open/Closed Principle (OCP)**: Open for extension, closed for modification
|
||||
- **Dependency Inversion Principle (DIP)**: Depend on abstractions, not concretions
|
||||
- **Interface Segregation Principle (ISP)**: Small, focused interfaces
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### Java (Spring Boot)
|
||||
- Classes: PascalCase (e.g., `DashboardController`)
|
||||
- Methods: camelCase (e.g., `getAllDashboards`)
|
||||
- Variables: camelCase (e.g., `dashboardRepository`)
|
||||
- Constants: UPPER_SNAKE_CASE (e.g., `API_VERSION`)
|
||||
|
||||
### Python (FastAPI)
|
||||
- Classes: PascalCase (e.g., `ServiceStatus`)
|
||||
- Functions: snake_case (e.g., `get_home_assistant_entities`)
|
||||
- Variables: snake_case (e.g., `service_config`)
|
||||
- Constants: UPPER_SNAKE_CASE (e.g., `SERVICES`)
|
||||
|
||||
### JavaScript/TypeScript (Node.js, React)
|
||||
- Classes: PascalCase (e.g., `DashboardComponent`)
|
||||
- Functions: camelCase (e.g., `fetchServiceSpec`)
|
||||
- Variables: camelCase (e.g., `serviceStatus`)
|
||||
- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`)
|
||||
- **Java**: PascalCase classes, camelCase methods, UPPER_SNAKE_CASE constants
|
||||
- **Python**: PascalCase classes, snake_case functions, UPPER_SNAKE_CASE constants
|
||||
- **JavaScript/TypeScript**: PascalCase classes, camelCase functions, UPPER_SNAKE_CASE constants
|
||||
|
||||
## Function Design
|
||||
|
||||
### Small, Focused Functions
|
||||
- Maximum 20-30 lines per function
|
||||
- Single level of abstraction
|
||||
- Clear, descriptive names
|
||||
- Single responsibility
|
||||
|
||||
### Error Handling
|
||||
## Error Handling
|
||||
- Consistent error responses
|
||||
- Proper exception handling
|
||||
- User-friendly error messages
|
||||
- Logging for debugging
|
||||
|
||||
## Code Review Checklist
|
||||
|
||||
### Before Merging
|
||||
- [ ] All new code follows naming conventions
|
||||
- [ ] Error handling is implemented
|
||||
- [ ] Input validation is present
|
||||
@@ -76,49 +48,13 @@ alwaysApply: true
|
||||
- [ ] Tests are written and passing
|
||||
- [ ] Clean code principles are followed
|
||||
|
||||
### Documentation Review
|
||||
- [ ] README files are comprehensive
|
||||
- [ ] Clean code documentation is complete
|
||||
- [ ] Project structure is updated
|
||||
- [ ] Progress tracking is current
|
||||
- [ ] Links are working and relevant
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
### Unit Tests
|
||||
- Test business logic
|
||||
- Test error conditions
|
||||
- Test edge cases
|
||||
- Maintain high coverage
|
||||
|
||||
### Integration Tests
|
||||
- Test API endpoints
|
||||
- Test service interactions
|
||||
- Test error scenarios
|
||||
- Test configuration
|
||||
|
||||
### End-to-End Tests
|
||||
- Test critical user flows
|
||||
- Test service integration
|
||||
- Test error recovery
|
||||
- Test performance
|
||||
- **Unit Tests**: Test business logic, error conditions, edge cases
|
||||
- **Integration Tests**: Test API endpoints, service interactions
|
||||
- **End-to-End Tests**: Test critical user flows, service integration
|
||||
|
||||
## Performance Guidelines
|
||||
|
||||
### Database Optimization
|
||||
- Use appropriate indexes
|
||||
- Implement connection pooling
|
||||
- Use lazy loading where appropriate
|
||||
- Optimize queries
|
||||
|
||||
### Caching
|
||||
- Implement appropriate caching
|
||||
- Use Redis for distributed caching
|
||||
- Cache frequently accessed data
|
||||
- Implement cache invalidation
|
||||
|
||||
### Resource Management
|
||||
- Proper cleanup of resources
|
||||
- Memory leak prevention
|
||||
- Connection pooling
|
||||
- Database optimization with appropriate indexes
|
||||
- Implement caching strategies
|
||||
- Proper resource management
|
||||
- Efficient algorithms
|
||||
@@ -6,76 +6,26 @@ alwaysApply: true
|
||||
|
||||
# Documentation Standards
|
||||
|
||||
## README Requirements
|
||||
Every service and major component MUST have a comprehensive README.md file that includes:
|
||||
When working with documentation files, follow these standards:
|
||||
|
||||
### Service README Requirements
|
||||
- **Service Overview**: Purpose, port, and main functionality
|
||||
- **Architecture**: Key components and their responsibilities
|
||||
- **Features**: Core capabilities and integrations
|
||||
- **API Endpoints**: Available endpoints with descriptions
|
||||
- **Configuration**: Environment variables and settings
|
||||
- **Development**: Setup, running, and testing instructions
|
||||
- **Dependencies**: Required packages and versions
|
||||
- **Clean Code**: Reference to CLEAN_CODE.md file
|
||||
## Required Documentation Files
|
||||
- **Main README**: @README.md
|
||||
- **Project Structure**: @docs/structure.txt
|
||||
- **Progress Tracking**: @docs/progress.md
|
||||
- **Clean Code Guide**: @CLEAN_CODE.md
|
||||
|
||||
### Frontend README Requirements
|
||||
- **Component Structure**: Directory organization and component hierarchy
|
||||
- **Development Setup**: Installation and running instructions
|
||||
- **Architecture**: Clean code principles and patterns
|
||||
- **API Integration**: Service communication and error handling
|
||||
- **Offline Mode**: Resilience features and fallback behavior
|
||||
- **Testing**: Unit and integration testing guidelines
|
||||
## Service Documentation
|
||||
Each service MUST have:
|
||||
- **README.md**: Service overview, setup, and usage
|
||||
- **CLEAN_CODE.md**: Clean code implementation details
|
||||
|
||||
## Documentation Folder Structure
|
||||
The `docs/` folder MUST contain:
|
||||
## Frontend Documentation
|
||||
- **README.md**: @frontend/README.md
|
||||
- **Clean Code**: @frontend/CLEAN_CODE.md
|
||||
- **Resilience**: @frontend/RESILIENCE.md
|
||||
|
||||
### Required Files
|
||||
- **specs.md**: Project specifications and requirements
|
||||
- **structure.txt**: Complete project directory structure
|
||||
- **progress.md**: Development progress and completed tasks
|
||||
- **FRONTEND_REFACTORING.md**: Frontend clean code refactoring summary
|
||||
|
||||
### Documentation Updates
|
||||
- Update `structure.txt` when adding new files or directories
|
||||
- Update `progress.md` when completing tasks or milestones
|
||||
- Update service-specific READMEs when modifying functionality
|
||||
- Update main README.md when adding new features or services
|
||||
|
||||
## Clean Code Documentation
|
||||
Every service MUST have a CLEAN_CODE.md file that includes:
|
||||
|
||||
### Required Sections
|
||||
- **Architecture Overview**: Service structure and organization
|
||||
- **Clean Code Principles**: SRP, OCP, DIP, ISP applications
|
||||
- **Code Quality Improvements**: Before/after examples
|
||||
- **Best Practices**: Technology-specific guidelines
|
||||
- **Performance Optimizations**: Caching, async operations, etc.
|
||||
- **Testing Strategy**: Unit, integration, and E2E testing
|
||||
- **Code Review Checklist**: Quality assurance guidelines
|
||||
- **Future Improvements**: Enhancement roadmap
|
||||
|
||||
## Documentation Quality Checklist
|
||||
|
||||
### README Quality
|
||||
- [ ] Clear service overview and purpose
|
||||
- [ ] Complete setup and running instructions
|
||||
- [ ] API endpoint documentation
|
||||
- [ ] Configuration examples
|
||||
- [ ] Development guidelines
|
||||
- [ ] Links to related documentation
|
||||
|
||||
### Clean Code Documentation
|
||||
- [ ] Architecture overview included
|
||||
- [ ] Clean code principles explained
|
||||
- [ ] Code examples provided
|
||||
- [ ] Best practices documented
|
||||
- [ ] Testing strategies outlined
|
||||
- [ ] Future improvements listed
|
||||
|
||||
### Project Documentation
|
||||
- [ ] Structure.txt is up to date
|
||||
- [ ] Progress.md reflects current status
|
||||
- [ ] All services have README files
|
||||
- [ ] All services have CLEAN_CODE.md files
|
||||
- [ ] Main README.md is comprehensive
|
||||
## Documentation Updates
|
||||
- Update @docs/structure.txt when adding new files
|
||||
- Update @docs/progress.md when completing tasks
|
||||
- Update service READMEs when modifying functionality
|
||||
- Keep all documentation current and comprehensive
|
||||
@@ -6,99 +6,44 @@ alwaysApply: false
|
||||
|
||||
# Frontend Standards
|
||||
|
||||
## Component Design
|
||||
When working with frontend files, follow these standards:
|
||||
|
||||
### React Components
|
||||
- Single responsibility per component
|
||||
- Props validation with PropTypes
|
||||
- Error boundary protection
|
||||
- Reusable and composable design
|
||||
- Maximum 50 lines per component file
|
||||
## Documentation References
|
||||
- **Frontend README**: @frontend/README.md
|
||||
- **Clean Code Guide**: @frontend/CLEAN_CODE.md
|
||||
- **Resilience Features**: @frontend/RESILIENCE.md
|
||||
|
||||
### Component Structure
|
||||
```
|
||||
src/
|
||||
├── components/
|
||||
│ ├── common/ # Reusable UI components
|
||||
│ ├── dashboard/ # Dashboard-specific components
|
||||
│ └── [main components] # Main application components
|
||||
├── hooks/ # Custom React hooks
|
||||
├── services/ # API and external services
|
||||
├── utils/ # Utility functions
|
||||
└── constants/ # Configuration constants
|
||||
```
|
||||
## Component Structure
|
||||
Follow the structure defined in @frontend/README.md:
|
||||
- **Common Components**: @frontend/src/components/common/
|
||||
- **Dashboard Components**: @frontend/src/components/dashboard/
|
||||
- **Custom Hooks**: @frontend/src/hooks/
|
||||
- **API Services**: @frontend/src/services/
|
||||
- **Utilities**: @frontend/src/utils/
|
||||
- **Constants**: @frontend/src/constants/
|
||||
|
||||
## Clean Code Principles
|
||||
Apply the principles detailed in @frontend/CLEAN_CODE.md:
|
||||
- Single Responsibility Principle
|
||||
- Component Composition
|
||||
- Error Handling with Error Boundaries
|
||||
- Performance Optimization
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### JavaScript/TypeScript
|
||||
- Classes: PascalCase (e.g., `DashboardComponent`)
|
||||
- Functions: camelCase (e.g., `fetchServiceSpec`)
|
||||
- Variables: camelCase (e.g., `serviceStatus`)
|
||||
- Constants: UPPER_SNAKE_CASE (e.g., `API_CONFIG`)
|
||||
|
||||
### File Organization
|
||||
## File Organization
|
||||
- Component files: PascalCase (e.g., `Dashboard.js`)
|
||||
- Hook files: camelCase with 'use' prefix (e.g., `useServiceStatus.js`)
|
||||
- Utility files: camelCase (e.g., `errorHandling.js`)
|
||||
- Constant files: camelCase (e.g., `index.js`)
|
||||
|
||||
## Clean Code Principles
|
||||
|
||||
### Single Responsibility Principle (SRP)
|
||||
- Each component has one clear purpose
|
||||
- `SystemStatsCards` only handles system statistics display
|
||||
- `ServiceStatusList` only manages service status display
|
||||
- `StatusIcon` only renders status icons
|
||||
|
||||
### Don't Repeat Yourself (DRY)
|
||||
- Centralized status icon logic in `StatusIcon` component
|
||||
- Reusable loading component in `LoadingSpinner`
|
||||
- Centralized error handling in `utils/errorHandling.js`
|
||||
- All constants extracted to `constants/index.js`
|
||||
|
||||
### Component Composition
|
||||
- Large components broken into smaller, focused components
|
||||
- Clear prop interfaces with PropTypes validation
|
||||
- Easy to test and maintain
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Error Boundaries
|
||||
- `ErrorBoundary` component for graceful error recovery
|
||||
- Development-friendly error details
|
||||
- User-friendly error messages
|
||||
|
||||
### Offline Mode
|
||||
- Service status monitoring
|
||||
- Fallback data when services unavailable
|
||||
- Automatic retry mechanisms
|
||||
- Clear status indicators
|
||||
|
||||
## Performance
|
||||
|
||||
### Component Optimization
|
||||
- Smaller components = better React optimization
|
||||
- Reduced re-renders through focused components
|
||||
- Memoization opportunities for pure components
|
||||
|
||||
### Code Splitting Ready
|
||||
- Modular structure supports code splitting
|
||||
- Easy to lazy load dashboard components
|
||||
- Clear separation enables tree shaking
|
||||
|
||||
## Testing
|
||||
|
||||
### Testable Components
|
||||
- Pure functions in utils
|
||||
- Isolated component logic
|
||||
- Clear prop interfaces
|
||||
- Mockable dependencies
|
||||
|
||||
### Test Structure
|
||||
```javascript
|
||||
describe('SystemStatsCards', () => {
|
||||
it('renders CPU usage correctly', () => {
|
||||
// Test focused component
|
||||
});
|
||||
});
|
||||
```
|
||||
## Component Design
|
||||
- Single responsibility per component
|
||||
- Maximum 50 lines per component file
|
||||
- Props validation with PropTypes
|
||||
- Error boundary protection
|
||||
- Reusable and composable design
|
||||
@@ -6,105 +6,51 @@ alwaysApply: true
|
||||
|
||||
# Project Structure Standards
|
||||
|
||||
## Directory Organization
|
||||
When working with any files, follow these structure standards:
|
||||
|
||||
### Service Structure
|
||||
```
|
||||
services/[service-name]/
|
||||
├── src/ # Source code
|
||||
├── tests/ # Test files
|
||||
├── docs/ # Service-specific documentation
|
||||
├── README.md # Service documentation
|
||||
├── CLEAN_CODE.md # Clean code implementation
|
||||
├── package.json/pom.xml # Dependencies
|
||||
└── Dockerfile # Container configuration
|
||||
```
|
||||
|
||||
### Frontend Structure
|
||||
```
|
||||
frontend/
|
||||
├── src/
|
||||
│ ├── components/ # React components
|
||||
│ │ ├── common/ # Reusable components
|
||||
│ │ └── dashboard/ # Dashboard-specific components
|
||||
│ ├── hooks/ # Custom hooks
|
||||
│ ├── services/ # API services
|
||||
│ ├── utils/ # Utility functions
|
||||
│ ├── constants/ # Configuration constants
|
||||
│ └── [app files] # Main application files
|
||||
├── public/ # Static assets
|
||||
├── README.md # Frontend documentation
|
||||
├── CLEAN_CODE.md # Clean code implementation
|
||||
├── RESILIENCE.md # Offline mode features
|
||||
└── package.json # Dependencies
|
||||
```
|
||||
|
||||
## File Naming
|
||||
|
||||
### Service Files
|
||||
- Source files: Follow language conventions
|
||||
- Documentation: README.md, CLEAN_CODE.md
|
||||
- Configuration: package.json, pom.xml, requirements.txt
|
||||
- Docker: Dockerfile, Dockerfile.dev
|
||||
|
||||
### Frontend Files
|
||||
- Components: PascalCase (e.g., `Dashboard.js`)
|
||||
- Hooks: camelCase with 'use' prefix (e.g., `useServiceStatus.js`)
|
||||
- Utilities: camelCase (e.g., `errorHandling.js`)
|
||||
- Constants: camelCase (e.g., `index.js`)
|
||||
## Project Structure Reference
|
||||
Follow the complete project structure defined in @docs/structure.txt
|
||||
|
||||
## Documentation Structure
|
||||
- **Main README**: @README.md
|
||||
- **Project Structure**: @docs/structure.txt
|
||||
- **Progress Tracking**: @docs/progress.md
|
||||
- **Clean Code Guide**: @CLEAN_CODE.md
|
||||
|
||||
### Required Documentation
|
||||
- **README.md**: Service overview and setup
|
||||
- **CLEAN_CODE.md**: Clean code implementation
|
||||
- **Progress tracking**: In docs/progress.md
|
||||
- **Structure updates**: In docs/structure.txt
|
||||
## Service Structure
|
||||
Each service MUST follow the structure defined in @docs/structure.txt:
|
||||
- **API Gateway**: @services/api-gateway/ with README.md and CLEAN_CODE.md
|
||||
- **Service Adapters**: @services/service-adapters/ with README.md and CLEAN_CODE.md
|
||||
- **API Docs**: @services/api-docs/ with README.md and CLEAN_CODE.md
|
||||
|
||||
### Documentation Updates
|
||||
- Update when adding new files or directories
|
||||
- Update when completing tasks or milestones
|
||||
- Update when modifying functionality
|
||||
- Update when adding new features or services
|
||||
## Frontend Structure
|
||||
Follow the structure defined in @frontend/README.md:
|
||||
- **Components**: @frontend/src/components/
|
||||
- **Hooks**: @frontend/src/hooks/
|
||||
- **Services**: @frontend/src/services/
|
||||
- **Utils**: @frontend/src/utils/
|
||||
- **Constants**: @frontend/src/constants/
|
||||
|
||||
## File Naming Conventions
|
||||
- **Service Files**: Follow language conventions (Java, Python, Node.js)
|
||||
- **Frontend Files**: PascalCase components, camelCase functions
|
||||
- **Documentation**: README.md, CLEAN_CODE.md, RESILIENCE.md
|
||||
|
||||
## Documentation Updates
|
||||
- Update @docs/structure.txt when adding new files
|
||||
- Update @docs/progress.md when completing tasks
|
||||
- Update service READMEs when modifying functionality
|
||||
- Keep all documentation current and comprehensive
|
||||
|
||||
## Configuration Files
|
||||
|
||||
### Environment Configuration
|
||||
- Use .env files for environment variables
|
||||
- Provide .env.example templates
|
||||
- Document all required variables
|
||||
- Use consistent naming conventions
|
||||
|
||||
### Docker Configuration
|
||||
- Multi-stage builds for production
|
||||
- Multi-stage Docker builds for production
|
||||
- Development-specific Dockerfiles
|
||||
- Health checks in containers
|
||||
- Proper base image selection
|
||||
|
||||
## Git Structure
|
||||
|
||||
### Branching Strategy
|
||||
- main: Production-ready code
|
||||
- develop: Integration branch
|
||||
- feature/*: Feature development
|
||||
- hotfix/*: Critical fixes
|
||||
|
||||
### Commit Messages
|
||||
- Use conventional commit format
|
||||
- Include scope when relevant
|
||||
- Provide clear descriptions
|
||||
- Reference issues when applicable
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Pre-commit Checks
|
||||
- Code formatting
|
||||
- Linting
|
||||
- Type checking
|
||||
- Test execution
|
||||
|
||||
### Pre-merge Checks
|
||||
- Code formatting and linting
|
||||
- Type checking and test execution
|
||||
- Code review approval
|
||||
- Test coverage requirements
|
||||
- Documentation updates
|
||||
- Security scans
|
||||
Reference in New Issue
Block a user