Skip to content

Latest commit

 

History

History
933 lines (730 loc) · 19.2 KB

DevelopmentReleaseProcess.md

File metadata and controls

933 lines (730 loc) · 19.2 KB

Development and Release Process

Table of Contents

  1. Introduction
  2. Git Conventions
  3. Development Process
  4. Hotfix Process
  5. Release Process
  6. React Native Specific Steps
  7. Version Management
  8. Build Generation
  9. Store Deployment

Introduction

This document outlines the development workflow, release process, and deployment procedures for the React Native Atomic Design project. Following these processes ensures consistent code quality, smooth releases, and reliable deployments.

Purpose:

  • Standardize development workflow
  • Ensure code quality through review processes
  • Maintain consistent versioning across platforms
  • Streamline release and deployment procedures
  • Document React Native specific build and deployment steps

Git Conventions

Branch Strategy

The project follows a Git Flow-inspired branching strategy:

Main Branches

  • master (or main): Production-ready code. Always deployable.
  • develop: Integration branch for development. Latest development changes.

Supporting Branches

  • feature/*: New features or enhancements
  • bugfix/*: Bug fixes for development
  • release/${releaseName}: Release preparation branches
  • hotfix/*: Critical production fixes

Branch Naming Conventions

Feature Branches:

feature/add-search-functionality
feature/implement-dark-mode
feature/repository-detail-screen

Bugfix Branches:

bugfix/fix-loading-state
bugfix/correct-api-error-handling
bugfix/resolve-memory-leak

Release Branches:

release/v1.0.0
release/v1.1.0
release/v2.0.0

Hotfix Branches:

hotfix/critical-crash-fix
hotfix/security-patch
hotfix/urgent-api-fix

Commit Message Format

Follow the Conventional Commits specification:

<type>(<scope>): <subject>

<body>

<footer>

Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, missing semicolons, etc.)
  • refactor: Code refactoring
  • test: Adding or updating tests
  • chore: Maintenance tasks (dependencies, build config, etc.)

Examples:

feat(home): add pull-to-refresh functionality

fix(api): handle network timeout errors

docs(readme): update installation instructions

refactor(components): extract common card styles

chore(deps): update axios to latest version

Guidelines:

  • Use present tense ("add" not "added")
  • Use imperative mood ("move" not "moves")
  • First line should be 50 characters or less
  • Reference issues in footer: Closes #123

PR Approval Requirements

Before merging:

  1. ✅ Code follows Code Conventions
  2. ✅ All tests pass (yarn test)
  3. ✅ Linting passes (yarn lint)
  4. ✅ No TypeScript errors
  5. ✅ PR description is clear and complete
  6. ✅ At least one code review approval
  7. ✅ Branch is up to date with target branch

PR Template:

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Tested on iOS
- [ ] Tested on Android

## Checklist
- [ ] Code follows conventions
- [ ] Self-review completed
- [ ] Comments added for complex logic
- [ ] Documentation updated

Development Process

Small Tasks Workflow (< 500 LOC)

For small features, bug fixes, or improvements:

  1. Create Feature Branch:

    git checkout develop
git pull origin develop
git checkout -b feature/task-name

  2. Develop and Commit:

    # Make changes
git add .
git commit -m "feat(scope): description"

  3. Keep Branch Updated:

    git checkout develop
git pull origin develop
git checkout feature/task-name
git rebase develop

  4. Create Pull Request:

    • Target: develop
    • Fill out PR template
    • Request review
    • Address review comments

  5. Merge:

    • After approval, merge to develop
    • Delete feature branch

Large Tasks Workflow (with Sub-tasks)

For large features requiring multiple PRs:

  1. Create Feature Branch:

    git checkout develop
git checkout -b feature/large-feature

  2. Break into Sub-tasks:

    • Create sub-branches from feature branch
    • Each sub-task should be < 500 LOC
    • Merge sub-tasks into feature branch
    # Sub-task 1
git checkout -b feature/large-feature/subtask-1
# ... work and PR to feature/large-feature

# Sub-task 2
git checkout feature/large-feature
git checkout -b feature/large-feature/subtask-2
# ... work and PR to feature/large-feature

  3. Final Integration:

    • Merge feature branch to develop when complete
    • Ensure all sub-tasks are integrated and tested

PR Creation and Review Process

  1. Before Creating PR:

    # Ensure branch is up to date
git checkout develop
git pull origin develop
git checkout feature/your-branch
git rebase develop

# Run tests and linting
yarn test
yarn lint

  2. Create PR:

    • Push branch to remote
    • Create PR on GitHub/GitLab
    • Fill out PR template
    • Add reviewers
    • Link related issues

  3. Review Process:

    • Address review comments
    • Update PR with fixes
    • Request re-review if needed
    • Wait for approval

  4. Merge:

    • Squash and merge (preferred for feature branches)
    • Or rebase and merge (for cleaner history)
    • Delete branch after merge

Rebase vs Merge Guidelines

Use Rebase When:

  • Updating feature branch with latest develop
  • Cleaning up commit history before merge
  • Working on feature branches
git checkout feature/your-branch
git rebase develop

Use Merge When:

  • Merging feature branch to develop
  • Merging release branch to master
  • Preserving branch history
git checkout develop
git merge feature/your-branch

Avoid:

  • Rebasing shared/public branches
  • Rebasing after PR is created (unless coordinated)

Dev-notes.txt Usage

If using dev-notes.txt for tracking:

  • Keep notes in branch-specific files
  • Document breaking changes
  • Note configuration changes
  • List dependencies added/removed
  • Include migration steps if needed

Hotfix Process

Hotfixes are for critical production issues that need immediate fixes.

Branch Creation from Master

  1. Create Hotfix Branch:

    git checkout master
git pull origin master
git checkout -b hotfix/critical-issue-description

  2. Fix the Issue:

    • Make minimal changes to fix the issue
    • Add tests if applicable
    • Update documentation if needed

  3. Commit:

    git add .
git commit -m "fix(scope): critical issue description"

Version Update Process

  1. Update Version in package.json:

    {
  "version": "1.0.1"  // Patch version increment
}

  2. Update Version in app.json:

    {
  "version": "1.0.1"
}

  3. Update iOS Version:

    • Open ios/codeSampleReactNative.xcodeproj in Xcode
    • Update CFBundleShortVersionString in Info.plist
    • Update CFBundleVersion (build number)

  4. Update Android Version:

    • Edit android/app/build.gradle:
    android {
    defaultConfig {
        versionCode 2  // Increment
        versionName "1.0.1"
    }
}

Build Generation

iOS Build (.ipa)

  1. Archive in Xcode:

    # Open workspace
open ios/codeSampleReactNative.xcworkspace
    • Select "Any iOS Device" or "Generic iOS Device"
    • Product → Archive
    • Wait for archive to complete

  2. Export IPA:

    • In Organizer, select archive
    • Click "Distribute App"
    • Choose distribution method (App Store, Ad Hoc, Enterprise)
    • Follow prompts to export .ipa file

  3. Alternative: Command Line (if Fastlane configured):

    cd ios
fastlane build

Android Build (.aab for Play Store)

  1. Generate Release AAB:

    cd android
./gradlew bundleRelease
    • Output: android/app/build/outputs/bundle/release/app-release.aab

  2. Generate APK (if needed):

    ./gradlew assembleRelease
    • Output: android/app/build/outputs/apk/release/app-release.apk

Testing and QA Approval

  1. Internal Testing:

    • Test on physical devices (iOS and Android)
    • Test critical paths
    • Verify fix resolves the issue
    • Check for regressions

  2. QA Review:

    • Submit build to QA team
    • Provide test cases
    • Document changes in release notes
    • Wait for QA approval

  3. Staging Testing (if applicable):

    • Deploy to TestFlight (iOS) or Internal Testing (Android)
    • Limited user testing
    • Collect feedback

Store Deployment

iOS App Store

  1. Upload to App Store Connect:

    • Use Xcode Organizer or Transporter app
    • Upload .ipa file
    • Wait for processing

  2. Submit for Review:

    • Go to App Store Connect
    • Select app version
    • Fill out "What's New" section
    • Submit for review
    • Monitor review status

Google Play Store

  1. Upload to Play Console:

    • Go to Play Console
    • Select app
    • Create new release
    • Upload .aab file
    • Fill release notes

  2. Review and Rollout:

    • Review release details
    • Start with internal testing track
    • Promote to production after validation
    • Consider gradual rollout (10% → 50% → 100%)

Tagging and Release Notes

  1. Create Git Tag:

    git checkout master
git pull origin master
git tag -a v1.0.1 -m "Hotfix: Critical issue fix"
git push origin v1.0.1

  2. Create GitHub Release:

    • Go to Releases page
    • Click "Draft a new release"
    • Select tag
    • Add release notes: 
      ## Hotfix v1.0.1

### Fixed
- Critical crash on repository list load
- API timeout handling

### Changed
- Updated error messages for better UX

Branch Merging Strategy

  1. Merge to Master:

    git checkout master
git merge hotfix/critical-issue-description
git push origin master

  2. Merge to Develop:

    git checkout develop
git merge hotfix/critical-issue-description
git push origin develop

  3. Delete Hotfix Branch:

    git branch -d hotfix/critical-issue-description
git push origin --delete hotfix/critical-issue-description

Release Process

Release Branch Creation

  1. Create Release Branch:

    git checkout develop
git pull origin develop
git checkout -b release/v1.1.0
git push origin release/v1.1.0

  2. Purpose:

    • Finalize release
    • Bug fixes only (no new features)
    • Version updates
    • Documentation updates

Version Management

Update versions in all required files:

  1. package.json:

    {
  "version": "1.1.0"
}

  2. app.json:

    {
  "version": "1.1.0"
}

  3. iOS (Info.plist):

    • CFBundleShortVersionString: "1.1.0"
    • CFBundleVersion: Increment build number

  4. Android (build.gradle):

    android {
    defaultConfig {
        versionCode 3  // Increment
        versionName "1.1.0"
    }
}

Build Generation and Distribution

Follow the same build process as hotfixes:

  1. iOS:

    • Archive in Xcode
    • Export .ipa
    • Upload to App Store Connect

  2. Android:

    • Generate release AAB
    • Upload to Play Console

QA Approval Process

  1. Pre-Release Testing:

    • Full regression testing
    • Test on multiple devices
    • Test on both platforms
    • Performance testing
    • Security review

  2. Release Candidate:

    • Tag release candidate: v1.1.0-rc1
    • Distribute to QA team
    • Collect and address feedback
    • Create new RC if needed

  3. Final Approval:

    • QA sign-off
    • Product owner approval
    • Technical lead approval

Store Deployment

iOS App Store

  1. Prepare for Submission:

    • Complete App Store Connect metadata
    • Prepare screenshots
    • Write release notes
    • Set pricing and availability

  2. Submit for Review:

    • Submit build for review
    • Monitor review status
    • Respond to review feedback if needed

  3. Release:

    • Manual release after approval
    • Or automatic release on approval
    • Monitor crash reports and reviews

Google Play Store

  1. Prepare Release:

    • Complete store listing
    • Prepare screenshots and graphics
    • Write release notes
    • Set content rating

  2. Rollout Strategy:

    • Start with internal testing
    • Move to closed testing (beta)
    • Gradual production rollout:
      • 10% of users (monitor for 24-48 hours)
      • 50% of users (monitor for 24-48 hours)
      • 100% rollout

  3. Monitor:

    • Crash reports
    • User reviews
    • Performance metrics
    • Rollback if critical issues found

Tagging and Release Notes

  1. Create Release Tag:

    git checkout release/v1.1.0
git tag -a v1.1.0 -m "Release v1.1.0"
git push origin v1.1.0

  2. Release Notes Template:

    # Release v1.1.0

## 🎉 New Features
- Added repository search functionality
- Implemented pull-to-refresh
- Added dark mode support

## 🐛 Bug Fixes
- Fixed memory leak in repository list
- Corrected API error handling
- Resolved iOS crash on app launch

## 🔧 Improvements
- Improved loading states
- Enhanced error messages
- Performance optimizations

## 📱 Platform Updates
- iOS: Minimum version iOS 15.0
- Android: Minimum API 21

## 📦 Dependencies
- Updated React Native to 0.83.1
- Updated axios to 1.13.2

Branch Merging Strategy

  1. Merge to Master:

    git checkout master
git merge release/v1.1.0
git push origin master

  2. Merge to Develop:

    git checkout develop
git merge release/v1.1.0
git push origin develop

  3. Delete Release Branch:

    git branch -d release/v1.1.0
git push origin --delete release/v1.1.0

React Native Specific Steps

Build Commands

Development Builds

iOS:

# Start Metro bundler
yarn start

# Run on iOS simulator
yarn ios

# Run on specific simulator
yarn ios --simulator="iPhone 15 Pro"

# Run on connected device
yarn ios --device

Android:

# Start Metro bundler
yarn start

# Run on Android emulator
yarn android

# Run on specific device
yarn android --deviceId=<device-id>

# Run on connected device
yarn android --device

Production Builds

iOS:

# Clean build
cd ios
xcodebuild clean -workspace codeSampleReactNative.xcworkspace -scheme codeSampleReactNative

# Build for device (requires signing)
# Use Xcode for production builds

Android:

# Clean build
cd android
./gradlew clean

# Build release APK
./gradlew assembleRelease

# Build release AAB (for Play Store)
./gradlew bundleRelease

EAS Build (Expo Application Services)

If using EAS Build (not currently configured):

# Install EAS CLI
npm install -g eas-cli

# Configure
eas build:configure

# Build for iOS
eas build --platform ios

# Build for Android
eas build --platform android

# Build for both
eas build --platform all

Fastlane Setup

If using Fastlane (not currently configured):

iOS Fastfile:

lane :build do
  increment_build_number
  build_app(
    workspace: "codeSampleReactNative.xcworkspace",
    scheme: "codeSampleReactNative"
  )
end

lane :beta do
  build
  upload_to_testflight
end

Android Fastfile:

lane :build do
  gradle(
    task: "bundle",
    build_type: "Release"
  )
end

lane :beta do
  build
  upload_to_play_store(track: "internal")
end

Version Code Management

iOS Version Management

Info.plist:

<key>CFBundleShortVersionString</key>
<string>1.1.0</string>
<key>CFBundleVersion</key>
<string>3</string>

Build Number Rules:

  • Increment for each build submitted to App Store
  • Can be same across hotfixes if not submitted
  • Must be unique for each App Store submission

Android Version Management

build.gradle:

android {
    defaultConfig {
        versionCode 3        // Integer, must increment
        versionName "1.1.0"   // User-facing version
    }
}

Version Code Rules:

  • Must be unique and incrementing
  • Each Play Store upload requires higher versionCode
  • Can't decrease versionCode
  • Use versionName for user-facing version

iOS Specific Deployment Steps

  1. Prerequisites:

    • Apple Developer account
    • App Store Connect access
    • Valid provisioning profiles
    • Code signing certificates

  2. Archive Process:

    • Open .xcworkspace (not .xcodeproj)
    • Select "Any iOS Device" or "Generic iOS Device"
    • Product → Archive
    • Wait for archive completion

  3. Distribution:

    • Use Organizer to distribute
    • Choose App Store distribution
    • Upload to App Store Connect
    • Wait for processing (10-30 minutes)

  4. App Store Connect:

    • Select build in TestFlight or App Store
    • Complete metadata if needed
    • Submit for review
    • Monitor review status

Android Specific Deployment Steps

  1. Prerequisites:

    • Google Play Developer account
    • Play Console access
    • Signing key (keystore file)
    • App signing configured

  2. Signing Configuration:

    android {
    signingConfigs {
        release {
            storeFile file("release.keystore")
            storePassword "password"
            keyAlias "release"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

  3. Build Process:

    cd android
./gradlew clean
./gradlew bundleRelease

  4. Play Console:

    • Go to Play Console
    • Select app
    • Create new release
    • Upload AAB file
    • Fill release notes
    • Review and rollout

Gradual Rollout Strategy

Google Play Gradual Rollout:

  1. Internal Testing:

    • Upload to internal testing track
    • Test with internal team
    • Fix critical issues

  2. Closed Testing (Beta):

    • Move to closed testing track
    • Invite beta testers
    • Collect feedback

  3. Production Rollout:

    • Start with 10% rollout
    • Monitor for 24-48 hours
    • Check crash reports and reviews
    • Increase to 50% if stable
    • Monitor for 24-48 hours
    • Full rollout to 100%

iOS TestFlight:

  • Internal testing (up to 100 testers)
  • External testing (up to 10,000 testers)
  • Production release after App Store approval

Monitoring and Rollback

Post-Deployment Monitoring:

  • Monitor crash reports (Firebase Crashlytics, Sentry)
  • Check user reviews and ratings
  • Monitor performance metrics
  • Track API errors and timeouts

Rollback Procedure:

iOS:

  • Can't rollback once released
  • Must submit new version to fix issues
  • Can pause new downloads in App Store Connect

Android:

  • Can halt rollout in Play Console
  • Can rollback to previous version
  • Can unpublish if critical issues

Remember: Always test thoroughly before release. A well-tested release is better than a rushed one.