DEV Community: Rishi Vachhani

Streamline Your Flutter Development: Complete CI/CD Pipeline with GitHub Actions and Google Play Store Deployment

Rishi Vachhani — Sat, 30 Aug 2025 11:13:44 +0000

Streamline Your Flutter Development: Complete CI/CD Pipeline with GitHub Actions and Google Play Store Deployment

As Flutter applications grow in complexity, manual building and deployment processes become time-consuming and error-prone. Implementing a robust CI/CD (Continuous Integration/Continuous Deployment) pipeline can dramatically improve your development workflow, reduce human errors, and ensure consistent releases.

In this comprehensive guide, we'll walk through setting up an automated CI/CD pipeline using GitHub Actions that builds your Flutter app, runs tests, and deploys directly to the Google Play Store.

What You'll Learn

Setting up GitHub Actions for Flutter CI/CD
Configuring automatic deployment to Google Play Store
Best practices for managing secrets and sensitive data
Real-world pipeline configuration with practical examples
Common pitfalls and how to avoid them

Prerequisites

Before we dive in, ensure you have:

A Flutter application hosted on GitHub
A Google Play Console developer account
Basic understanding of YAML and GitHub Actions
Android app signing key (we'll cover this)

Part 1: Understanding the CI/CD Pipeline

Our pipeline will consist of three main stages:

Continuous Integration (CI): Code validation, testing, and building
Continuous Deployment (CD): Automated deployment to Google Play Store
Monitoring: Pipeline health and deployment status tracking

Part 2: Setting Up Google Play Console

Step 1: Create a Service Account

Visit the Google Cloud Console
Create a new project or select an existing one
Navigate to "IAM & Admin" → "Service Accounts"
Click "Create Service Account"
Fill in the service account details:
- Name: flutter-ci-cd-service
- Description: Service account for Flutter CI/CD pipeline

Step 2: Configure Play Console Access

Go to Google Play Console
Navigate to "Setup" → "API access"
Link your Google Cloud project
Grant access to your service account with these permissions:
- Release manager: For uploading and releasing apps
- View app information: For reading app metadata

Step 3: Generate Service Account Key

In Google Cloud Console, go to your service account
Click "Keys" → "Add Key" → "Create new key"
Select "JSON" format
Download the key file (keep it secure!)

Part 3: Android App Signing Setup

Generate Upload Key

keytool -genkey -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Create key.properties

Create android/key.properties:

storePassword=your_keystore_password
keyPassword=your_key_password
keyAlias=upload
storeFile=upload-keystore.jks

Configure build.gradle

Update android/app/build.gradle:

// Add before android block
def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {
    // ... existing configuration

    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
            storePassword keystoreProperties['storePassword']
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

Part 4: GitHub Actions CI/CD Pipeline

Complete Workflow Configuration

Create .github/workflows/flutter-ci-cd.yml:

name: Flutter CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
  release:
    types: [ published ]

env:
  FLUTTER_VERSION: "3.24.0"
  JAVA_VERSION: "17"

jobs:
  # Continuous Integration Job
  test:
    name: Run Tests and Analysis
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: ${{ env.JAVA_VERSION }}

    - name: Setup Flutter
      uses: subosito/flutter-action@v2
      with:
        flutter-version: ${{ env.FLUTTER_VERSION }}
        channel: 'stable'
        cache: true

    - name: Install dependencies
      run: flutter pub get

    - name: Verify formatting
      run: dart format --output=none --set-exit-if-changed .

    - name: Analyze project source
      run: flutter analyze --fatal-infos

    - name: Run unit tests
      run: flutter test --coverage

    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        token: ${{ secrets.CODECOV_TOKEN }}
        file: coverage/lcov.info

  # Build Job
  build:
    name: Build APK and App Bundle
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: ${{ env.JAVA_VERSION }}

    - name: Setup Flutter
      uses: subosito/flutter-action@v2
      with:
        flutter-version: ${{ env.FLUTTER_VERSION }}
        channel: 'stable'
        cache: true

    - name: Install dependencies
      run: flutter pub get

    - name: Decode keystore
      run: |
        echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > android/app/keystore.jks

    - name: Create key.properties
      run: |
        echo "storeFile=keystore.jks" > android/key.properties
        echo "storePassword=${{ secrets.KEYSTORE_PASSWORD }}" >> android/key.properties
        echo "keyPassword=${{ secrets.KEY_PASSWORD }}" >> android/key.properties
        echo "keyAlias=${{ secrets.KEY_ALIAS }}" >> android/key.properties

    - name: Build APK
      run: flutter build apk --release

    - name: Build App Bundle
      run: flutter build appbundle --release

    - name: Upload APK artifact
      uses: actions/upload-artifact@v4
      with:
        name: release-apk
        path: build/app/outputs/flutter-apk/app-release.apk

    - name: Upload App Bundle artifact
      uses: actions/upload-artifact@v4
      with:
        name: release-aab
        path: build/app/outputs/bundle/release/app-release.aab

  # Deploy to Google Play Store
  deploy:
    name: Deploy to Play Store
    runs-on: ubuntu-latest
    needs: build
    if: github.event_name == 'release' && github.event.action == 'published'

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Download App Bundle artifact
      uses: actions/download-artifact@v4
      with:
        name: release-aab

    - name: Create service account JSON
      run: |
        echo "${{ secrets.GOOGLE_SERVICES_JSON }}" | base64 --decode > service-account.json

    - name: Deploy to Play Store
      uses: r0adkll/upload-google-play@v1.1.3
      with:
        serviceAccountJson: service-account.json
        packageName: com.yourcompany.yourapp
        releaseFiles: app-release.aab
        track: internal
        status: completed
        inAppUpdatePriority: 2
        userFraction: 0.5
        whatsNewDirectory: distribution/whatsnew
        mappingFile: build/app/outputs/mapping/release/mapping.txt

  # Notify on deployment
  notify:
    name: Send Deployment Notification
    runs-on: ubuntu-latest
    needs: deploy
    if: always()

    steps:
    - name: Notify Slack
      if: needs.deploy.result == 'success'
      uses: 8398a7/action-slack@v3
      with:
        status: success
        text: '🚀 Flutter app successfully deployed to Play Store!'
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

    - name: Notify on failure
      if: needs.deploy.result == 'failure'
      uses: 8398a7/action-slack@v3
      with:
        status: failure
        text: '❌ Flutter app deployment failed!'
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Part 5: Advanced Pipeline Features

Multi-Environment Deployment

strategy:
  matrix:
    environment: [internal, alpha, production]
    include:
      - environment: internal
        track: internal
        user_fraction: 1.0
      - environment: alpha
        track: alpha
        user_fraction: 0.1
      - environment: production
        track: production
        user_fraction: 1.0

Conditional Deployments

- name: Deploy to Internal Track
  if: github.ref == 'refs/heads/develop'
  uses: r0adkll/upload-google-play@v1.1.3
  with:
    track: internal

- name: Deploy to Production
  if: github.event_name == 'release'
  uses: r0adkll/upload-google-play@v1.1.3
  with:
    track: production

Part 6: Security Best Practices

1. Managing Secrets Securely

Required GitHub Secrets

Navigate to your repository → Settings → Secrets and variables → Actions:

KEYSTORE_BASE64          # Base64 encoded keystore file
KEYSTORE_PASSWORD        # Keystore password
KEY_PASSWORD            # Key password
KEY_ALIAS               # Key alias
GOOGLE_SERVICES_JSON    # Base64 encoded service account JSON
CODECOV_TOKEN          # Optional: for code coverage
SLACK_WEBHOOK_URL      # Optional: for notifications

Encoding Files to Base64

# Encode keystore
base64 -i upload-keystore.jks | pbcopy

# Encode service account JSON
base64 -i service-account.json | pbcopy

2. Environment-Specific Configurations

Create separate secret sets for different environments:

DEV_KEYSTORE_BASE64
STAGING_KEYSTORE_BASE64
PROD_KEYSTORE_BASE64

3. Secret Rotation Strategy

Rotate service account keys every 90 days
Use time-limited access tokens when possible
Implement secret scanning in your repository
Never commit secrets to version control

4. Access Control

# Restrict deployment to specific branches
if: github.ref == 'refs/heads/main' && github.event_name == 'push'

# Require manual approval for production deployments
environment:
  name: production
  url: https://play.google.com/store/apps/details?id=com.yourcompany.yourapp

Part 7: Enhanced Pipeline Features

Code Quality Gates

- name: Run custom lints
  run: flutter analyze --fatal-warnings

- name: Check code coverage threshold
  run: |
    COVERAGE=$(flutter test --coverage | grep -o '[0-9]*\.[0-9]*%' | head -1 | sed 's/%//')
    if (( $(echo "$COVERAGE < 80" | bc -l) )); then
      echo "Coverage $COVERAGE% is below threshold of 80%"
      exit 1
    fi

Dynamic Version Management

- name: Update version
  run: |
    VERSION_CODE=${{ github.run_number }}
    VERSION_NAME="${{ github.ref_name }}-${{ github.run_number }}"

    # Update pubspec.yaml
    sed -i "s/version: .*/version: $VERSION_NAME+$VERSION_CODE/" pubspec.yaml

Parallel Testing

test:
  strategy:
    matrix:
      test-type: [unit, widget, integration]
  steps:
    - name: Run ${{ matrix.test-type }} tests
      run: flutter test test/${{ matrix.test-type }}

Part 8: Troubleshooting Common Issues

Issue 1: Build Failures

Problem: Gradle build fails due to dependency conflicts

Solution:

- name: Clean build cache
  run: |
    flutter clean
    flutter pub get
    cd android && ./gradlew clean

Issue 2: Keystore Issues

Problem: Keystore not found or invalid

Solution:

- name: Verify keystore
  run: |
    if [ ! -f "android/app/keystore.jks" ]; then
      echo "Keystore file not found!"
      exit 1
    fi
    keytool -list -keystore android/app/keystore.jks -storepass ${{ secrets.KEYSTORE_PASSWORD }}

Issue 3: Play Console Upload Failures

Problem: Service account lacks permissions

Solution:

Verify service account has "Release Manager" role
Ensure app is properly linked in Play Console
Check track configuration (internal/alpha/beta/production)

Part 9: Monitoring and Notifications

Slack Integration

- name: Notify deployment status
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    fields: repo,message,commit,author,action,eventName,ref,workflow
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Email Notifications

- name: Send email notification
  if: failure()
  uses: dawidd6/action-send-mail@v3
  with:
    server_address: smtp.gmail.com
    server_port: 465
    username: ${{ secrets.EMAIL_USERNAME }}
    password: ${{ secrets.EMAIL_PASSWORD }}
    subject: 🚨 Flutter CI/CD Pipeline Failed
    body: |
      The CI/CD pipeline for ${{ github.repository }} has failed.

      Commit: ${{ github.sha }}
      Branch: ${{ github.ref }}
      Author: ${{ github.actor }}

      Check the logs: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
    to: dev-team@yourcompany.com
    from: ci-cd@yourcompany.com

Part 10: Performance Optimization

Caching Strategy

- name: Cache Flutter dependencies
  uses: actions/cache@v4
  with:
    path: |
      ~/.pub-cache
      ${{ runner.tool_cache }}/flutter
    key: ${{ runner.os }}-flutter-${{ hashFiles('**/pubspec.lock') }}
    restore-keys: |
      ${{ runner.os }}-flutter-

- name: Cache Gradle dependencies
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}

Build Optimization

- name: Enable Gradle daemon
  run: |
    mkdir -p ~/.gradle
    echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties
    echo "org.gradle.parallel=true" >> ~/.gradle/gradle.properties
    echo "org.gradle.configureondemand=true" >> ~/.gradle/gradle.properties

Part 11: Advanced Security Measures

1. Secret Scanning

Add .github/workflows/security-scan.yml:

name: Security Scan

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0

    - name: Run TruffleHog OSS
      uses: trufflesecurity/trufflehog@main
      with:
        path: ./
        base: main
        head: HEAD

2. Dependency Vulnerability Scanning

- name: Run dependency audit
  run: |
    flutter pub deps --json | dart run security_audit

- name: Check for outdated packages
  run: flutter pub outdated --exit-if-outdated

3. Code Signing Verification

- name: Verify app signing
  run: |
    jarsigner -verify -verbose -certs build/app/outputs/bundle/release/app-release.aab

Part 12: Multi-Platform Support

iOS Deployment Extension

build-ios:
  name: Build iOS
  runs-on: macos-latest
  needs: test

  steps:
  - uses: actions/checkout@v4

  - name: Setup Flutter
    uses: subosito/flutter-action@v2
    with:
      flutter-version: ${{ env.FLUTTER_VERSION }}
      channel: 'stable'

  - name: Install dependencies
    run: flutter pub get

  - name: Build iOS
    run: flutter build ios --release --no-codesign

  - name: Build IPA
    run: |
      cd ios
      xcodebuild -workspace Runner.xcworkspace \
                 -scheme Runner \
                 -configuration Release \
                 -destination generic/platform=iOS \
                 -archivePath build/Runner.xcarchive \
                 archive

Essential Resources and Links

Google Play Console & APIs

Google Play Console - Main dashboard for app management
Google Cloud Console - Service account management
Google Play Developer API - API documentation
Play Console Help - Official support docs

GitHub Actions Resources

GitHub Actions Marketplace - Find reusable actions
Flutter Action - Official Flutter setup action
Upload Google Play Action - Play Store deployment

Security Tools

TruffleHog - Secret detection
GitGuardian - Secret monitoring service

Best Practices Checklist

Security

✅ Use GitHub Secrets for all sensitive data
✅ Encode binary files (keystore, service account) as Base64
✅ Implement secret rotation schedule
✅ Enable branch protection rules
✅ Use environment-specific deployments
✅ Implement secret scanning
✅ Never commit secrets to repository

Performance

✅ Cache Flutter and Gradle dependencies
✅ Use matrix builds for parallel testing
✅ Optimize Docker images if using containers
✅ Implement incremental builds
✅ Use artifact caching between jobs

Reliability

✅ Implement proper error handling
✅ Add retry mechanisms for flaky operations
✅ Use health checks before deployment
✅ Implement rollback strategies
✅ Monitor deployment success rates

Code Quality

✅ Run automated tests (unit, widget, integration)
✅ Enforce code formatting standards
✅ Implement static analysis
✅ Check code coverage thresholds
✅ Scan for security vulnerabilities

Monitoring Your Pipeline

Key Metrics to Track

Build Success Rate: Percentage of successful builds
Deployment Frequency: How often you deploy
Lead Time: Time from commit to production
Mean Time to Recovery: Time to fix failed deployments

Setting Up Monitoring

- name: Record metrics
  run: |
    echo "build_duration=${{ job.duration }}" >> metrics.log
    echo "commit_sha=${{ github.sha }}" >> metrics.log
    echo "deployment_time=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> metrics.log

Common Pitfalls and Solutions

1. Version Conflicts

Problem: Flutter/Dart version mismatches
Solution: Pin specific versions in workflow and use version matrix for testing

2. Keystore Management

Problem: Keystore security and access
Solution: Use Base64 encoding and GitHub Secrets, never commit keystore files

3. Play Console Permissions

Problem: Service account lacks necessary permissions
Solution: Grant "Release Manager" role and verify API access configuration

4. Build Artifacts

Problem: Large artifact sizes affecting pipeline performance
Solution: Implement artifact cleanup and use efficient compression

Conclusion

Implementing a robust CI/CD pipeline for your Flutter application transforms your development workflow from manual, error-prone processes to automated, reliable deployments. This setup ensures that every code change is thoroughly tested, properly built, and securely deployed to the Google Play Store.

Key benefits you'll experience:

Faster Release Cycles: Automated processes reduce deployment time from hours to minutes
Improved Code Quality: Automated testing catches issues before they reach production
Enhanced Security: Proper secret management and automated security scanning
Better Collaboration: Standardized processes make team collaboration smoother
Reduced Human Error: Automation eliminates manual deployment mistakes

Next Steps

Implement the basic pipeline and test with a simple Flutter app
Gradually add advanced features like multi-environment deployment
Set up monitoring and alerting for pipeline health
Establish a secret rotation schedule
Document your team's deployment processes

Remember, CI/CD is an iterative process. Start simple, monitor your pipeline's performance, and continuously improve based on your team's needs and feedback.

Additional Resources

Flutter DevOps Guide - Official Flutter deployment docs
Android App Bundle Guide - Google's app bundle documentation
GitHub Actions Documentation - Complete GitHub Actions reference

Happy coding, and may your deployments be ever smooth! 🚀

Setting Up Auto Scaling Groups and Load Balancer on AWS EC2: A Step-by Step Guide

Rishi Vachhani — Sun, 27 Apr 2025 08:30:09 +0000

Ensuring high availability and scalability for your application is crucial when deploying on AWS.

In this guide, we'll walk through setting up Auto Scaling Groups (ASG), an Application Load Balancer (ALB), and a Target Group on AWS EC2.
By the end, you'll have a fully functional architecture that dynamically scales based on demand.

Launch EC2 Instance Before setting up Auto Scaling, start by launching an EC2 instance and configuring it to serve traffic.

Install Nginx on the Instance
Once your instance is running, install an Nginx server to serve a default page:

sudo apt update && sudo apt install nginx -y

When you access the instance's public IP in a browser, you should see the default Nginx welcome page.

Create a Target Group A Target Group is needed to route traffic from the Load Balancer to the EC2 instances.

Steps to Create a Target Group:

Navigate to Target Groups in the AWS EC2 dashboard.
Click Create Target Group.
Select Instances as the target type.
Specify the port (80/443) and protocol (HTTP/HTTPS).
Attach the previously launched EC2 instances.
AWS will now check the health status of the instances.

Create an Application Load Balancer (ALB) The Load Balancer distributes incoming traffic across multiple instances, improving availability and reliability.

Steps to Create a Load Balancer:

Navigate to Load Balancers in the AWS dashboard.
Click Create Load Balancer and select Application Load Balancer.
Choose Internet-facing as the scheme.
Configure Security Groups to allow HTTP/HTTPS traffic.
Select Regions and Availability Zones as needed.
Attach the previously created Target Group.

Click Create Load Balancer.

Once created, you can access the instances using the Load Balancer's DNS name.

Create a Launch Template A Launch Template defines the instance configuration for Auto Scaling.

Steps to Create a Launch Template:

Navigate to Launch Templates in AWS.

Click Create Launch Template.
Choose an instance type (e.g., t2.micro, t3.medium).
Configure network settings and attach necessary storage.
Select Security Groups and Key Pairs for authentication.
Save and create the Launch Template.

Set Up an Auto Scaling Group (ASG) Auto Scaling ensures that your application scales up or down based on demand.

Steps to Create an Auto Scaling Group:

Navigate to Auto Scaling Groups in AWS.
Click Create Auto Scaling Group.
Select the previously created Launch Template.
Choose VPC settings and Subnets.
Define the desired number of instances to maintain.
Integrate with the Load Balancer and Target Group.
Configure additional settings like Scaling Policies.

Click Create Auto Scaling Group.

Configure Dynamic Scaling Policies A Dynamic Scaling Policy adjusts the number of instances based on traffic.

Steps to Configure Scaling Policies:

Navigate to Auto Scaling Groups.
Select Scaling Policies.
Define Scaling Conditions such as CPU utilization or request rate.
Choose Step Scaling or Target Tracking Scaling.
Set thresholds for scaling in and out dynamically.

Save the policy — AWS will now adjust instances automatically based on demand.

Final Architecture Overview
After completing these steps, your AWS setup will include:

✅ EC2 instances running Nginx
✅ An Application Load Balancer distributing traffic
✅ A Target Group managing instance health
✅ An Auto Scaling Group ensuring dynamic scaling

This architecture ensures high availability, fault tolerance, and scalability for your AWS-hosted applications.

Conclusion
By following this guide, you've successfully deployed a scalable and fault-tolerant AWS infrastructure using Auto Scaling, Load Balancer, and Target Groups.
This setup ensures your application remains highly available even during traffic spikes.

📌 For a detailed step-by-step guide with images, download the PDF here

👥 Thanks to @vikram_patel, @shreyansh_1904, @karmpatel, and @thisaakash for their collaboration.

Automating CPU and Memory Utilization Logging with Cron Jobs on Windows and Linux

Rishi Vachhani — Fri, 14 Mar 2025 16:08:58 +0000

Introduction

Monitoring system performance is crucial for maintaining a healthy and efficient computing environment. In this guide, we will automate the logging of CPU and memory utilization every 15 minutes using scheduled tasks in Windows and cron jobs in Linux. We will also ensure that a new log file is created daily.

Why This is Useful in Everyday Life

Automating system monitoring can greatly simplify daily operations, especially for developers, system administrators, and IT professionals. Instead of manually checking system resource usage, automated logging allows:

Early detection of performance issues – Identify spikes in CPU or memory usage before they cause major slowdowns or crashes.
Efficient troubleshooting – Logs provide historical data, making it easier to diagnose and resolve performance problems.
Better resource planning – Analyze usage trends over time to optimize system resources.
Peace of mind – Once set up, the script runs in the background without user intervention, ensuring continuous monitoring.

Setting Up the Python Script

Before setting up the scheduled jobs, let's create a Python script that logs CPU and memory utilization.

Install Required Dependencies

We will use the psutil module to fetch CPU and memory utilization. If you haven't installed it yet, run:

pip install psutil

Python Script to Log System Utilization

Create a script named system_monitor.py with the following code:

import psutil
import datetime
import os

def log_system_utilization():
    today = datetime.datetime.now().strftime("%Y-%m-%d")
    log_dir = "logs"
    os.makedirs(log_dir, exist_ok=True)
    log_file = os.path.join(log_dir, f"cpu_memory_log_{today}.txt")

    with open(log_file, "a") as f:
        timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        cpu_usage = psutil.cpu_percent(interval=1)
        memory_usage = psutil.virtual_memory().percent
        log_entry = f"{timestamp} - CPU Usage: {cpu_usage}% | Memory Usage: {memory_usage}%\n"
        f.write(log_entry)
        print(log_entry)

if __name__ == "__main__":
    log_system_utilization()

This script:

Creates a log directory if it doesn’t exist.
Generates a new log file daily.
Logs CPU and memory usage every time it runs.

Scheduling the Script on Linux Using Cron Job

In Linux, we use cron jobs to automate script execution.

Step 1: Open the Crontab Editor

Run the following command:

crontab -e

Step 2: Add the Cron Job

Add the following line at the end of the file to run the script every 15 minutes:

*/15 * * * * /usr/bin/python3 /path/to/system_monitor.py

Explanation:

*/15 → Runs every 15 minutes.
* * * * → Runs every hour, day, month, and weekday.
/usr/bin/python3 → Path to the Python interpreter.
/path/to/system_monitor.py → Full path to the script.

Step 3: Save and Exit

Save the file and exit. The cron job will now run every 15 minutes.

Step 4: Verify the Cron Job

To list scheduled cron jobs, run:

crontab -l

Scheduling the Script on Windows Using Task Scheduler

On Windows, we use Task Scheduler to automate the script execution.

Step 1: Open Task Scheduler

Press Win + R, type taskschd.msc, and hit Enter.

Step 2: Create a New Task

Click Create Basic Task.
Name it "System Utilization Logger" and click Next.

Step 3: Set the Trigger

Choose Daily and click Next.
Set the start time to midnight and repeat every day.
Click Next.

Step 4: Set the Action

Choose Start a Program and click Next.
Browse to the Python executable (e.g., C:\Python39\python.exe).
In the Add arguments field, enter the full path to system_monitor.py, e.g.:

   "C:\path\to\system_monitor.py"

Click Next and then Finish.

Step 5: Modify Task to Run Every 15 Minutes

Open Task Scheduler Library, right-click the created task, and select Properties.
Go to the Triggers tab and click Edit.
Select Repeat task every 15 minutes and Stop after 1 day.
Click OK and Apply.

Step 6: Test the Task

Right-click the task and select Run to ensure it executes correctly.

Conclusion

By following this guide, you've successfully automated system monitoring on both Linux and Windows. The script now runs every 15 minutes, generating daily logs to track CPU and memory utilization. This setup helps in proactive system monitoring and can be further enhanced with alert mechanisms or cloud storage integrations.

How This Makes Life Easier

Saves Time & Effort: No need to manually check system performance.
Improves System Stability: Prevent unexpected failures by analyzing logs.
Enhances Troubleshooting: Quickly identify patterns of high CPU/memory usage.
Scalable & Automated: Works on any system without manual intervention.

With this setup in place, you can focus on other important tasks while ensuring your system's performance is continuously monitored. 🚀

Let me know in the comments if you have any questions or suggestions!

@vikram_patel , @thisaakash , @shreyansh_1904, @karmpatel Thanks for colloborations.

Understanding Runlevels in Linux: A Complete Guide

Rishi Vachhani — Sat, 08 Mar 2025 05:42:08 +0000

Linux is a powerful and flexible operating system used in servers, embedded systems, and desktops worldwide. One of the essential components of Linux system administration is runlevels. Runlevels define the state of a Linux system by controlling the services and processes that run at startup.

Whether you’re troubleshooting boot issues or managing system services, understanding runlevels can significantly improve your Linux administration skills. In this blog, we’ll explore what runlevels are, where they are used, how to check the current runlevel, how to change it, and real-world use cases.

What Are Runlevels in Linux?

A runlevel in Linux is a mode of operation that determines what processes and services are active at a given time. Different runlevels are predefined for various system states, such as single-user mode, multi-user mode, or GUI mode. Traditionally, runlevels range from 0 to 6, each serving a specific purpose.

Standard Runlevels in Linux

The standard runlevels in SysVinit-based Linux distributions are:

Runlevel	Description
0	Halt (Shutdown)
1	Single-user mode (Maintenance Mode)
2	Multi-user mode without network
3	Full multi-user mode (CLI)
4	Unused (customizable)
5	Multi-user mode with GUI
6	Reboot

However, modern Linux distributions such as Ubuntu (16.04+), RHEL 7+, and CentOS 7+ have replaced SysVinit with systemd, where targets are used instead of runlevels.

Where Are Runlevels Used?

Runlevels are used in various scenarios, including:

System Boot Management — Define what services should start during boot.
Troubleshooting — Switching to single-user mode (Runlevel 1) helps in fixing critical system issues.
Server Configurations — Servers often run in Runlevel 3 (CLI mode) to save resources.
GUI vs CLI Switching — Users can switch between GUI (Runlevel 5) and CLI (Runlevel 3) as needed.
Custom System Modes — Runlevel 4 (unused by default) can be customized for specific requirements.

How to Check the Current Runlevel?

To check the current runlevel of your Linux system, use:

runlevel

Example Output:

N 5

Here, N indicates there was no previous runlevel change, and 5 represents the current runlevel (multi-user mode with GUI).

For systemd-based distributions, use:

systemctl get-default

Example Output:

graphical.target

This corresponds to Runlevel 5 in SysVinit.

How to Change Runlevels in Linux?

In SysVinit-based Systems

To switch to a different runlevel temporarily:

init <runlevel>

For example, to switch to runlevel 3:

init 3

Or:

telinit 3

To change the default runlevel permanently, edit the /etc/inittab file and modify this line:

default:5:initdefault:

Change 5 to your desired runlevel and reboot.

In Systemd-based Systems

To change the current runlevel (target) in systemd-based systems:

systemctl isolate multi-user.target

To set a default runlevel (target):

systemctl set-default multi-user.target

To switch back to GUI mode:

systemctl isolate graphical.target

Real-Time Use Cases of Runlevels

Recovering a Broken System — Boot into single-user mode (Runlevel 1) to fix misconfigured files or disk errors.
Running a Server Efficiently — Use Runlevel 3 (multi-user CLI mode) to optimize performance by disabling GUI.
Switching to Maintenance Mode — If you need to perform updates or maintenance, temporarily move to Runlevel 1.
Troubleshooting Network Issues — Runlevel 2 (no network) helps isolate networking problems.
Automating Startup Services — Customize runlevel scripts for specific startup configurations.

Conclusion

Understanding Linux runlevels is crucial for system administrators and advanced users. Whether you’re using an old SysVinit-based system or a modern systemd-based one, knowing how to check, change, and utilize runlevels can improve system management.

By mastering runlevels, you can efficiently manage services, troubleshoot issues, and optimize system performance. Start experimenting with different runlevels today to enhance your Linux skills!

@vikram_patel, @thisaakash , @shreyansh_1904 Thanks for colloborations.

Git Reset: Understanding and Using It Effectively

Rishi Vachhani — Thu, 06 Mar 2025 16:14:34 +0000

Git is a powerful Distributed Version Control System (DVCS) packed with commands that let developers manage their codebases efficiently. With its robust capabilities, Git provides flexibility for high-level operations while giving full access to its internals. It is fast, scalable, and an indispensable tool for modern development workflows.

What is Git Reset?

git reset is one of Git’s most versatile yet often misunderstood commands. It allows developers to undo changes at different levels of their repository. Depending on the options provided (--soft, --mixed, --hard), it manipulates three key components of Git:

Commit Tree (HEAD): Tracks the latest commit in the current branch.
Staging Index: Where changes are prepared for a commit.
Working Directory: Reflects local files and modifications.

Each mode of git reset changes these components in different ways.

The Three Modes of Git Reset

1. Soft Reset (`git reset --soft`)

Moves the HEAD pointer to the specified commit.
Keeps all changes in the staging area and working directory untouched.
Use case: When you want to modify or amend a commit without losing your staged changes.

 git reset --soft <commit-hash>

2. Mixed Reset (`git reset --mixed`) (default)

Moves the HEAD pointer to the specified commit.
Unstages changes but retains them in the working directory.
Use case: When you need to re-stage or redo your commit preparation.

 git reset --mixed <commit-hash>

3. Hard Reset (`git reset --hard`)

Moves the HEAD pointer to the specified commit.
Deletes all changes from both the staging area and the working directory.
Use case: When you want to discard all changes and return to a clean state.

 git reset --hard <commit-hash>

How Git Reset Works Internally

To understand how git reset works, let’s look at the three core components of a Git repository:

HEAD: Points to the latest commit in the current branch.
Index: The staging area for changes ready to be committed.
Working Directory: The local files and their current state.

Use Cases for Git Reset

Use --soft for minor adjustments: Great for tweaking or amending recent commits without losing any work.
Stick to --mixed for safe resets: Less destructive since it preserves changes in the working directory.
Be cautious with --hard: Only use it when you are sure you no longer need the uncommitted changes. Back up your work if necessary.
Avoid git reset on shared branches: Resetting history on shared branches can cause conflicts and confusion.
Leverage git reflog for recovery: If you reset to the wrong commit, git reflog can help you recover lost references.

Conclusion

Understanding git reset is essential for managing code efficiently. Whether making small corrections, undoing staged changes, or completely resetting a repository, knowing when and how to use git reset ensures a smooth development workflow.

By mastering git reset, developers can confidently navigate version history, fix mistakes, and optimize their Git experience.

@vikram_patel , @thisaakash , @shreyansh_1904 Thanks for collaborations.