Forem: Animesh Pathak

How diffChangelog and Snapshots Work Together

Animesh Pathak — Thu, 12 Feb 2026 04:01:24 +0000

When I started formalizing Database DevOps practices, one recurring issue kept surfacing: schema drift.

Development was ahead of staging. Production had emergency hotfixes. QA sometimes had “just one small tweak” that never made it back to version control. Keeping schemas aligned across environments wasn’t just operational hygiene, it became foundational for reliability.

That’s where Liquibase OSS and specifically diffChangelog became a core part of my schema syncing strategy.

This article explains two things:

How I use diffChangelog for database schema synchronization
How it actually works internally using snapshots

Because understanding the mechanics changes how confidently you automate it.

The Schema Sync Problem

In practice, schema syncing usually looks like one of these scenarios:

Dev schema contains new tables not yet in staging
Production has an index created manually during incident mitigation
A column datatype differs across environments
Constraints exist in one environment but not another

Traditional approaches involve manual inspection or ad-hoc SQL comparison scripts. Both are error-prone. With Liquibase OSS, I approach this differently. Instead of comparing raw SQL, I compare database states.

The Command That Powers Schema Sync

Here’s the command I typically use:

liquibase diffChangelog \
  --referenceUrl=jdbc:postgresql://localhost:5432/dev \
  --url=jdbc:postgresql://localhost:5432/prod \
  --changeLogFile=schema-sync.xml

Conceptually:

Reference database → Desired schema
Target database → Actual schema
Output → ChangeLog needed to align target with reference

But what’s happening under the hood?

How diffChangelog Actually Works?

The power of diffChangelog lies in Liquibase’s snapshot engine. It does not compare SQL files. It does not parse DDL text. Instead, it performs a structured, object-level comparison.

Step 1: Snapshot Creation

Liquibase generates a snapshot of each database. A snapshot is an in-memory representation of schema metadata. This includes:

Schemas
Tables
Columns
Indexes
Primary keys
Foreign keys
Unique constraints
Sequences
Views
Data types

Here’s the lifecycle:

flowchart TD
    A[Reference Database] --> B[Snapshot Generator]
    C[Target Database] --> D[Snapshot Generator]
    B --> E[Reference Snapshot Object]
    D --> F[Target Snapshot Object]

Liquibase queries database metadata (e.g., information_schema in PostgreSQL) and converts it into structured objects. Instead of raw SQL text, it now has two object graphs representing each schema.

Step 2: Object Graph Comparison

Once both snapshots are built, Liquibase runs its diff engine.

flowchart TD
    E[Reference Snapshot] --> G[Diff Engine]
    F[Target Snapshot] --> G
    G --> H[Difference Classification]

Differences are categorized as:

Missing → Exists in reference, not in target
Unexpected → Exists in target, not in reference
Changed → Exists in both but attributes differ

For example:

A table in dev but not prod → Missing
An index in prod but not dev → Unexpected
Column length differs → Changed

This classification becomes the foundation for changelog generation.

Step 3: ChangeLog Generation

Liquibase then converts differences into changeSets.

flowchart TD
    H[Difference Classification] --> I[ChangeLog Generator]
    I --> J[Generated ChangeLog File]

Example outputs:

If a table is missing:

<createTable tableName="orders">
   ...
</createTable>

If a datatype changed:

<modifyDataType tableName="users" columnName="email" newDataType="varchar(255)"/>

The result is a deployable changelog that synchronizes the target schema.

How I Use This for Schema Syncing?

Understanding the internal mechanics allows me to apply it confidently in real workflows.

1. Environment Alignment (Dev → Staging → Prod)

When dev is the source of truth:

flowchart LR
    A[Dev Schema] --> B[Snapshot]
    C[Prod Schema] --> D[Snapshot]
    B --> E[Diff Engine]
    D --> E
    E --> F[Sync ChangeLog]
    F --> G[Apply to Prod]

This ensures production moves forward predictably.

2. Drift Detection in CI

I often run diffChangelog during CI to detect unauthorized drift :

Deploy known changelog to temp DB
Snapshot production
Compare
Fail pipeline if differences exist

flowchart TD
    A[Git Controlled Schema] --> B[Temp DB]
    C[Production DB] --> D[Snapshot]
    B --> E[Snapshot]
    D --> F[Diff Engine]
    E --> F
    F --> G{Drift Detected?}
    G -->|Yes| H[Fail Build]
    G -->|No| I[Continue]

This gives me governance without slowing velocity.

3. Legacy Database Onboarding

For existing systems not yet version-controlled:

Snapshot production
Generate baseline changelog
Commit to Git
Transition into controlled migration model

diffChangelog becomes a bridge between unmanaged and managed schemas.

Important Practical Lessons

Over time, I’ve learned several nuances.

Snapshot Scope Matters

For large schemas, snapshot generation can be heavy. I use filters like:

--schemas=public
--includeObjects=table:users,index:users_email_idx

This keeps comparisons focused and performant.

Not Every Difference Should Be Deployed

Auto-generated constraint names can differ across environments. Index naming strategies may vary. I always review generated changeLogs before applying them. Schema syncing is powerful but it must be deliberate.

Snapshots Enable Determinism

The biggest realization for me was this - “diffChangelog is not comparing SQL text”. It is comparing structured schema models. That abstraction layer is what makes:

Cross-database comparison possible
CI automation reliable
Drift detection accurate
Schema syncing deterministic

Without snapshots, diffing would be brittle and vendor-specific.

Why This Matters in Database DevOps?

Schema syncing is not just about keeping environments tidy. It enables:

Predictable deployments
Audit traceability
Reduced incident risk
Environment parity
Controlled rollback strategies

Liquibase OSS gives me:

Snapshot generation
Object-level diffing
ChangeLog generation
Automated synchronization

All without requiring enterprise extensions.

Final Thoughts

When I think about database schema syncing today, I no longer see it as a manual reconciliation process. I see it as:

Snapshot state
Compare object graphs
Generate delta
Apply controlled synchronization

diffChangelog, powered by snapshots, turns schema comparison into a structured, automatable workflow. And once I understood how it works internally, I stopped treating it as a convenience command and started treating it as a foundational component of my Database DevOps architecture.

Observability for Databases in CI/CD

Animesh Pathak — Mon, 08 Sep 2025 09:36:44 +0000

When organizations think about continuous integration and continuous delivery (CI/CD), the focus often centers on application code: unit tests, build pipelines, automated deployments, and monitoring for microservices. But there’s a blind spot that frequently gets overlooked - “the database.”

Databases aren’t just another service; they are the backbone of modern applications. A schema change, performance regression, or even a small migration error can bring an entire release to a halt. This is why observability for databases in CI/CD pipelines has become critical, though it often remains under-prioritized.

In this blog, we’ll explore why observability matters for databases, what unique challenges it presents, and how teams can begin embedding observability into their database delivery workflows.

Why Observability Matters for Databases ?

When we think about observability in modern engineering, it often conjures up images of dashboards filled with service metrics, traces, and logs. But databases demand a different lens. They are stateful systems, deeply intertwined with application logic, and they evolve in ways that are more delicate and often riskier than application code itself.

A typical software deployment can be rolled back with relative ease. If an API misbehaves, the deployment can be reverted, and the system is usually restored quickly. Databases, however, do not follow this forgiving pattern. Schema changes are not simply “versioned” like code; they alter the shape of the data itself. Once an ALTER TABLE or a DROP COLUMN runs in production, undoing it can be slow, painful, and in some cases impossible without a full restore from backups. This makes the stakes of database delivery inherently higher.

Another reason observability matters is performance. Many organizations have faced situations where a release seemed successful, only to discover days later that a single schema tweak had increased query latency across the board. The application monitoring tools might show a spike in response times, but tracing that back to the exact migration can be like finding a needle in a haystack. With proper observability, the connection between “deployment event” and “query performance regression” becomes visible and actionable.

Finally, there’s the matter of speed versus safety. The promise of CI/CD is agility, faster releases, quicker iterations, and reduced time to market. Yet, rushing database deployments without adequate visibility is like driving a car at top speed with no dashboard indicators. You don’t know if you’re running low on fuel, if the engine is overheating, or if a tire is about to burst. Observability provides that feedback loop, enabling teams to move quickly while still protecting data integrity and system reliability.

In short: observability isn’t a “nice to have” for databases; it’s the foundation that makes modern database delivery feasible at scale.

Common Observability Challenges Unique to Databases

Adding observability for databases isn’t as straightforward as reusing traditional APM tools. Databases behave differently than stateless services. Here are a few pain points:

Black Box Migrations – Most teams treat migrations as fire-and-forget scripts. When they fail, root cause analysis is often tedious.
Drift Detection – Environments fall out of sync easily, leading to inconsistencies and unpredictable behavior in production.
Metrics Granularity – Beyond CPU and memory, teams need visibility into query execution times, index usage, and lock contention.
Tooling Fragmentation – Application monitoring stacks rarely integrate cleanly with database-native metrics.

Adding Observability in Database CI/CD Pipelines

So, how do we solve this? The answer lies in shifting observability left side, i.e. adding it into the pipeline rather than treating it as an afterthought.

Pre-Deployment Checks – Validate schema compatibility and dependencies before deploying.
Migration Visibility – Capture execution times, before/after states, and log outputs for every migration. Interestingly, migration strategies themselves can influence observability. For example, whether teams adopt a state-based or script-based model directly impacts how changes are tracked and monitored.
Real-Time Performance Monitoring – Extend existing observability stacks to monitor query latency and slow queries after deployment.
Drift Alerts – Automate schema comparison across environments to catch unapproved changes.
Feedback Loops – Build dashboards for developers and DBAs alike, encouraging shared ownership.

The Payoff: Faster, Safer Releases

By investing in observability, organizations gain:

Confidence in Deployments: Teams know changes are safe before they hit production.
Fewer Firefights: Early detection reduces late-night incidents and downtime.
Shared Responsibility: Observability bridges the gap between DevOps engineers and DBAs.
Better Business Outcomes: Faster releases, less downtime, and improved customer experience.

In other words, observability doesn’t just protect your database; it accelerates your delivery pipeline.

Conclusion

Database DevOps is no longer optional. As organizations adopt trunk-based development and rapid release cycles, databases must keep pace. Observability is the missing piece that ensures every schema change, migration, or deployment is executed with confidence.

Start small: integrate migration visibility, add drift detection, and connect your databases to your observability stack. The sooner you embed observability, the sooner your pipeline becomes both faster and safer.

Smarter Database DevOps with AI: From Changelogs to Intelligent Pipelines

Animesh Pathak — Thu, 04 Sep 2025 10:02:34 +0000

Databases have always been the “final boss” of DevOps. You can automate your CI/CD pipelines all you want, but when it comes to database deployments, teams often slow down. Manual changelogs, risky rollbacks, schema drift sound familiar?
But what if AI could help?
That’s exactly what we’re experimenting with in my side project based on Harness Database DevOps.

Why Databases Lag Behind in DevOps

Unlike application code, database changes are stateful and persistent. If you mess up a deployment, you can’t just roll back by redeploying a container. The cost of errors is high, and the tooling hasn’t always kept up with the speed of modern CI/CD.
Some common pain points:

Writing and maintaining changelogs is tedious.
Keeping environments (dev, staging, prod) in sync is tough.
Rollbacks are not always straightforward.
Drift happens, and often you catch it too late.

Where AI fits in?

This is where AI and intelligent agents come into play. Imagine describing your database change in plain English i.e. “Add a created_at column to the users table” and getting back a production ready changelog file.
Or even better: pasting your existing changelog, and asking the AI to insert new changes in the correct order while preserving history.
Some of the things we’ve been exploring:

AI-generated changelogs: From natural language to YAML/XML/JSON.
Editing existing changelogs: Insert new changesets without breaking old ones.
Environment-specific changes: Generate context-aware migrations for dev, staging, or prod.
Conflict detection: Use AI to flag duplicates or risky changes before deployment. Here’s a sneak peek of the prototype in action 👇

Beyond Changelogs: Towards Intelligent Pipelines

Changelogs are just the start. Once you bring AI into the Database DevOps loop, the possibilities get exciting:

Rollback strategy suggestions → Learn from past patterns to recommend safer rollbacks.
Conversational approvals → Approve or reject deployments via chat with natural language.

This isn’t about replacing DBAs or developers, it’s about giving them better tools, automating the repetitive parts, and reducing the risk of human error.

Try It Out

We’re still experimenting, but you can try the AI Changeset Generator on Hugging Face. And if you’re already deep into Database DevOps, we’d love to hear how you’d want AI to fit into your workflow. Would you trust it to write migrations? Spot drift? Recommend rollbacks?

[Boost]

Animesh Pathak — Wed, 30 Jul 2025 08:34:32 +0000

Animesh Pathak

Jul 30 '25

Why Your Git Branching Strategy Is Breaking Your Database Deployments

#git #database #devops #tooling

Comments

2 min read

Why Your Git Branching Strategy Is Breaking Your Database Deployments

Animesh Pathak — Wed, 30 Jul 2025 08:33:41 +0000

As DevOps and GitOps practices evolve, one area remains notoriously fragile: database deployments.

While application delivery has matured with CI/CD, many teams still struggle with schema changes, rollbacks, and environment consistency. One hidden reason? Poor Git branching strategies.

Many teams default to a "branch-per-environment" model (main → dev → qa → prod). It feels logical… until it isn't. Merge conflicts spike. Hotfixes drift. QA stops reflecting production. Your pipeline becomes a patchwork of manual interventions.

This approach creates drift, increases cognitive overhead, and slows down delivery. For stateful systems like databases, that risk multiplies.

Without a clean GitOps model, visibility is lost and rollbacks become nightmares.

🧠 The Better Approach: Trunk-Based GitOps for DBs

Adopt trunk-based development:

One main branch as the source of truth
Use contexts (e.g., dev, qa, prod) to control deployment per environment
Manage environments declaratively via metadata, not folders or branches
Promote via pipeline stages, not Git merges

✅ A Better Way: Trunk-Based GitOps for Databases

Instead of long-lived branches, adopt a trunk-based development model with GitOps principles:

Use a single main branch to track all database changes.
Apply contexts (dev, qa, prod) to control environment targeting.
Promote through environments using pipelines, not merges.
Keep your Git history clean and auditable.

This creates cleaner workflows, simplifies automation, and keeps all environments aligned with the same deployment logic.

🧰 Tools to Make It Work

We’re using this strategy with Harness Database DevOps, which supports:

Liquibase-native changelogs with context-based targeting.
CI/CD pipelines that pull from main and apply changes declaratively.
Rollbacks using rollback blocks, backups, or roll-forward techniques.
Git as the single source of truth.

The result? Database deployments that are safe, scalable, and reproducible.

💡 Conclusion

Avoiding per-environment branching is critical in modern Database DevOps. While it may appear organized at first, this approach often results in drift, merge conflicts, and inconsistent environments over time. Instead of creating separate branches for dev, qa, and prod, consolidate your workflow into a single mainline development branch.

By tagging changelogs with appropriate contexts, you can control where and how changes are applied—without duplicating files or relying on directory structures like /dev or /prod.

Maintaining all database changelogs in a single branch ensures consistency, traceability, and a reliable source of truth. Promotions between environments should be handled through automated pipelines, not Git merges.

Ultimately, embracing GitOps brings visibility, policy enforcement, and rollback control to database workflows. By combining declarative tooling with robust pipeline orchestration, teams can ship database changes as confidently as application code.

What’s Happening Inside Your Linux Kernel?

Animesh Pathak — Sat, 17 May 2025 10:18:06 +0000

Have you ever wondered how exactly your Linux system knows when a program is running, a file system is being mounted, or a new module is being loaded? It’s all happening deep inside the Linux kernel, and most of the time, we’re completely blind to it.

But what if I told you there’s a way to peek inside, without rebooting the system, installing special software, or breaking anything?

Welcome to the world of "kprobes", where you can trace important kernel events in real-time, like a system detective 🕵️‍♂️.

Let’s dive in.

Why Should You Care? 🤔

Let’s say you’re running containers in production. One day, something feels off—a container might be doing something it shouldn’t.

Is it spawning weird processes?
Is it trying to mount a new filesystem?
Is it trying to gain extra privileges?
Is someone loading a sketchy kernel module?

These are early warning signs of something going wrong—maybe a misconfigured app, maybe an attack. Kprobes let you catch these signs early.

What kernel functions we can trace?

Linux is full of functions, but we’ll focus on four powerful ones that reveal a lot about what’s going on:

1. `do_execve`: Process Launch Tracker 🚀

Whenever you run a program like ls, python, or a shell script, the Linux kernel calls a function named do_execve. This function is the gateway to launching any new executable in the system. Why is this important? Because if you're monitoring for suspicious activity, like an unexpected script suddenly running on your server:do_execve is your best friend. It's essentially a signal that something new is being executed. Think of it like someone opening a door and entering a new room in a secure building. Naturally, you’d want to know who just walked in and whether they belong there.

2. `security_capable`: Permission Checkpoint 🛡️

The security_capable function is called whenever a process tries to perform an action that requires special privileges like changing network configurations, modifying system time, or accessing restricted resources. It's a key part of Linux's internal permission checking system. In essence, this function asks: Does this process have the right capabilities? Monitoring this can reveal when processes are trying to act like an admin or escalate privileges. Imagine someone attempting to unlock the admin panel in a web app. Wouldn’t you want to know who they are and whether they should be allowed?

3. `security_sb_mount`: Filesystem Mount Auditor 🗂️

Every time a filesystem is mounted whether it’s an external drive, a virtual filesystem, or a container volume, the security_sb_mount function is called. Mount operations are usually routine, but they can also be exploited to access unauthorized data or escape from container environments. From a security perspective, this function lets you keep tabs on what’s being attached to your system and by whom. Think of it like plugging a USB stick into a laptop. What’s on it? Is it safe? Who’s doing it? eBPF can help you find out.

4. `load_module`: Kernel Code Gatekeeper 🧩

Linux is modular, and the kernel allows dynamic loading of new code modules, like drivers or extensions at runtime. This is managed by the load_module function. While many modules are harmless or necessary, some can introduce vulnerabilities or even backdoors. By tracing load_module, you can detect whenever new kernel code is being added. It’s like someone installing an app on your phone. Is it coming from a trusted source? Should it be there at all? Keeping an eye on this function gives you insight into what’s being added to the core of your OS.

How Do We Trace These Functions?

This is where kprobes come in. Think of kprobes as little spy cameras inside the kernel. You can place them at any function and they’ll quietly record what’s happening.

Here’s how the flow works:

You choose a kernel function, like do_execve.
You set a kprobe on it, which says: “Whenever this function is called, tell me.”
The system logs each call, including key details like PID, UID, and arguments.
You read the trace from a special file: /sys/kernel/debug/tracing/trace_pipe.

💬 Final Thoughts

Think of kernel tracing like having X-ray vision into your Linux system. You don’t need to guess what your containers or processes are doing, you will be able to see it.

Kprobes give you power, visibility, and control especially when something feels off but you don’t know where to start looking.

Ready to try it out? Start small, trace one function, and see what insights pop up. The Linux kernel is full of secrets it’s time to uncover them.

FAQs

1. What is `do_execve`, and why trace it?

The do_execve function is the kernel’s internal handler for the execve system call, responsible for loading a new program into a process’s address space and starting its execution. Tracing do_execve reveals exactly when and how processes are launched, making it invaluable for detecting unauthorized or unexpected binaries running on a system.

2. What does `security_capable` check?

The security_capable function is part of the Linux Security Modules (LSM) framework and is invoked whenever a process requests a privileged capability (e.g., CAP_SYS_ADMIN). Tracing this hook shows when processes attempt actions that require elevated privileges, helping to catch privilege escalations or policy violations.

3. What is `security_sb_mount`, and why is it important?

security_sb_mount is the LSM hook called whenever a filesystem is mounted (including container volumes). Monitoring this function can detect unauthorized mounts—which may indicate container escapes or illicit data access—by reporting details such as device path and filesystem type.

4. How do kprobes attach hooks to kernel functions?

Kprobes dynamically insert breakpoints into almost any kernel routine. You define a probe by writing a line like:

echo 'p:myprobe do_execve' > /sys/kernel/debug/tracing/kprobe_events

This tells the kernel to invoke your handler whenever do_execve runs. The recorded data is then read from /sys/kernel/debug/tracing/trace_pipe for live monitoring.

How to Effectively Vet Your Supply Chain for Optimal Performance

Animesh Pathak — Thu, 15 May 2025 09:09:50 +0000

In today’s world, software projects often rely on many open source libraries. While these libraries speed up development, they can also bring hidden risks if they are not checked carefully. A single unsafe library can compromise an entire project. SafeDep’s vet tool helps you guard your software supply chain by checking every library you use. Below is a detailed, step-by-step guide to understanding, installing, and using vet in your projects. But why is Supply Chain Security matter?

Understanding the Risk of Supply Chain Attacks

A supply chain attack happens when an attacker hides bad code in a library or package that many developers download. When you add that library to your project, the bad code can:

Steal sensitive information
Break parts of your application
Spread malware to users

Beyond Traditional Scanning

Supply chain attacks have surged, leveraging tactics such as malicious code injection, dependency confusion, and typosquatting. Conventional scanners focus narrowly on known CVEs, leaving blind spots in popularity, maintenance status, license compliance, and more. Modern organizations require a holistic solution that codifies and automates risk evaluation across multiple dimensions.

Introducing vet: Policy-Driven Supply Chain Protection

vet transforms security requirements into executable policies using the Common Expression Language (CEL). By treating security guardrails as code, you achieve:

Automated Compliance: Define rules once and enforce them across every build, pull request, and release.
Customizable Risk Tolerance: Craft filters for critical vulnerabilities, unacceptable licenses, low adoption, or missing maintenance.
Extensible Metadata: Leverage OSV vulnerability feeds, popularity metrics, maintenance indicators, extended license attributes, and OpenSSF Scorecards for third-party risk assessment.

Key Features

Capability	Description
Code Analysis & Filtering	Focus on high-impact risks using CEL filters to target critical issues only.
Direct OSV Integration	Pull up-to-date vulnerability data from the OSV ecosystem.
Popularity & Maintenance Checks	Block unvetted or unmaintained packages before they enter your codebase.
License & Compliance Controls	Enforce acceptable license policies automatically.
OpenSSF Scorecard Insights	Incorporate third-party security posture into approval workflows.
Transitive Dependency Coverage	Analyze both direct and transitive components for end-to-end visibility.
Filter Suites	Group multiple CEL filters into a single policy suite for complex guardrails.

Installation and Setup

Getting started with vet is straightforward:

Local CLI Installation

brew tap safedep/tap
brew install safedep/tap/vet

Initial Configuration

Create a policy.yml defining your filter suites:

filter_suites:
  default:
    filters:
      - block_high_severity
      - require_popularity
      - enforce_scorecard

Repository Scan

vet scan -D . --filter-suite default --fail-on-filter

Integrating vet into CI/CD Workflows

Seamless CI/CD integration is critical for “shift-left” security. vet offers native GitHub Action support, enabling policy execution on every pull request, commit, and release:

name: Supply Chain Security

on:
  pull_request:
    paths:
      - '**/*.go'
      - '**/*.js'

jobs:
  vet_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: safedep/vet-action@v1
        with:
          filter-suite: default
          fail-on-filter: true

Upon policy violation, vet automatically annotates pull requests with inline comments, detailing the failed filters and suggesting remediation steps. For teams using GitLab or Jenkins, vet can be executed via CLI in pipeline stages, with exit codes controlling build success. Furthermore, vet can emit SARIF output, integrating with security dashboards and code scanning interfaces for unified visibility.

Real-World Case Studies

Scenario: A global bank with hundreds of Java microservices sought to harden its supply chain against high-severity vulnerabilities and unmaintained packages.

Baseline Vulnerability Exposure: Prior to vet, the bank’s DevSecOps team found that, on average, 52% of pulled dependencies contained at least one high- or critical-severity CVE.
Policy Implementation:
- Block High-Severity CVEs: dependency.osv.vulnerabilities.any(v | v.severity in ["HIGH","CRITICAL"])
- Maintenance Check: Reject libraries with zero commits or releases in the last 12 months.
Integration: Embedded vet into the GitHub Actions pipeline across 120 repositories, running scans on every pull request.
Results Over Three Months:
- 85% reduction in dependencies with high-severity CVEs
- 70% fewer unmaintained packages entering the codebase, compared to a 30% industry average for mature banking organizations generating SBOMs and enforcing security policies
- Mean Time to Remediation (MTTR) for critical vulnerabilities improved from 72 hours pre-vet to 18 hours, outpacing the 66% of organizations that remediate within a day

Key Takeaways: By codifying high-severity and maintenance policies in CEL and automating enforcement, the bank not only slashed vulnerable dependencies but also accelerated remediation workflows, aligning with top-quartile performance in financial services.

Conclusion

SafeDep’s vet redefines software supply chain security through a policy-as-code approach that integrates seamlessly into development workflows. By consolidating metadata from OSV, OpenSSF Scorecards, popularity and maintenance indicators, and license attributes, vet provides a comprehensive, real-time defense against diverse supply chain threats.

Organizations can codify their security and compliance requirements in CEL filters, enforce them automatically in CI/CD pipelines, and empower developers with immediate, actionable feedback. Embracing vet enables teams to balance innovation and risk, ensuring only secure, compliant open source components advance through their pipelines - ultimately fostering resilient, trustworthy software delivery.

FAQ’s

What policies can I define with vet?

You can express any security or compliance requirement as CEL filters—critical CVEs, banned licenses, low popularity thresholds, end-of-life projects, or OpenSSF Scorecard minima—and group them into reusable filter suites.

How does vet obtain vulnerability data?

vet integrates directly with the OSV ecosystem, pulling the latest vulnerability feeds and mapping them to your dependencies in real time.

Can I scan transitive dependencies?

Yes. vet analyzes both direct and transitive dependencies to ensure end-to-end supply chain visibility and enforcement.

How do I integrate vet into my CI/CD pipeline?

Use the safedep/vet-action for GitHub Actions (or analogous steps for other systems) to run vet scan on every pull request and build, automatically blocking policy violations before code merges.

Is vet extensible to custom metadata sources?

While vet natively supports OSV, popularity, maintenance, license, and OpenSSF Scorecard data, the CEL-based architecture allows you to incorporate additional metadata feeds or internal risk indicators as needed.

References -

Visit SafeDep - https://safedep.io
Explore about SafeDep on GitHub - https://github.com/safedep/vet

How Liquibase Makes Life Easy for DB Admins

Animesh Pathak — Wed, 07 May 2025 06:30:00 +0000

Let’s be honest - managing database changes can sometimes feel like juggling fire. You’ve got multiple developers making updates, environments to manage, rollbacks to worry about, and let’s not forget those late-night “It worked on dev!” surprises.

But guess what? There's a tool that can help you stay ahead of the chaos. It’s called Liquibase, and it's like having a helpful assistant who always remembers what changes were made, who made them, and when. Today, we're going to break it down - what Liquibase is, how it works (especially with YAML), why it's useful, and how it's being used in real projects like mux-sql.

So grab your favourite cup of coffee ☕️, and let’s dive in!

What is Liquibase?

Liquibase is an open-source database change management tool. Think of it as version control, but for your database.

Just like Git helps developers manage changes in their code, Liquibase helps you manage changes in your database schema. It keeps track of all the changes you've made (like adding tables, modifying columns, or creating indexes) and applies them in a controlled, consistent way across different environments - dev, test, staging, production.

And yes, it works with most major databases: MySQL, PostgreSQL, Oracle, SQL Server, and many others.

Why Should You Care?

You might be thinking, “My team already handles DB scripts manually. Why switch?”

Here’s why Liquibase can make your life easier:

No More Manual Scripts: Say goodbye to writing and tracking V1__create_table.sql, V2__add_column.sql, and so on.
Tracks What’s Been Applied: It keeps a changelog and logs every change in a special table (DATABASECHANGELOG) inside your DB.
Works with CI/CD: Automate your DB updates during deployments.
Supports Rollbacks: Made a mistake? You can roll back changes with a command.
Clear Audit Trail: Know who changed what and when.

In short, Liquibase gives you control, clarity, and confidence when managing DB updates.

How Does It Work?

Liquibase works using something called a changelog. This is a file where you define all your database changes using a format like YAML, XML, JSON, or SQL. Each change is grouped into a changeset—a small, trackable unit of change.

Here's an example from the mux-sql app's Liquibase YAML file:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00

This snippet says: “Hey, create a table called users with id, username, and email columns. The id is the primary key and cannot be null.”

Once you run Liquibase, it reads this changelog, checks which changes haven’t been applied yet (based on the DATABASECHANGELOG table), and runs the SQL under the hood to make the changes. Easy, right?

YAML + Liquibase: A Perfect Match made in heaven

Many DBAs are familiar with SQL, but YAML might feel new. Don’t worry - YAML is just a human-readable way to structure data. It’s like writing your changes in plain English.

Why use YAML?

It’s clean and readable.
Great for code reviews.
Less error-prone than long SQL scripts.
Supported natively by Liquibase.

If you’ve ever worked with configuration files in Kubernetes, Docker Compose, or CI tools like GitHub Actions - you’ve already used YAML. You’re ahead of the game!

A Real-World Example: Mux + PostgreSQL

Let’s talk about something real.

The mux-sql project uses Liquibase with a YAML changelog to manage its database schema. It's a backend app built with Go, and like many projects, it needs to manage a growing database as new features are added.

Here’s how they’ve set things up:

They use a liquibase.yml file in the root of their project.
All database changes (like new tables, updates) are defined inside it.
Developers make schema changes by adding new changesets.
When the app is deployed, Liquibase applies only the new changes.
The team doesn’t have to guess what version the database is on—Liquibase handles it.

This approach keeps things clean, consistent, and avoids the “Did we run that script on staging?” drama.

CI/CD and Liquibase = New Power Duo

Now, let’s level up, iIf your team is using a CI/CD pipeline (like GitHub Actions, GitLab CI, or Jenkins), you can run Liquibase automatically whenever you deploy. Imagine this:

A developer creates a new table.
They add a new changeset to the YAML changelog.
They push their code.
Your CI pipeline runs, and Liquibase applies the new schema changes as part of the deploy.

Boom! Database updated, and everyone’s happy. No more hunting down SQL scripts or forgetting to run migrations.

But what About Rollbacks?

Mistakes happen. Maybe a changeset dropped the wrong column. Don’t worry—Liquibase has rollback support.

You can define a rollback inside your changeset like this:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00
      rollback:
        - dropTable:
            tableName: products

Now, if something goes wrong, you can just run:

liquibase rollbackCount 1

And it will undo that change. Peace of mind, built-in.

Best Practices for DB Admins Using Liquibase

Here are a few tips to make the most of Liquibase:

Use descriptive id and author in each changeset helps trace who did what.
Keep changelogs in version control (Git) treat schema as code.
Test locally before pushing changes always!
Use Liquibase commands to validate before applying changes: liquibase validate
Modularize your changelogs if your project gets big. You can include files.

The Learning Curve? Not So Steep!

Some folks might worry that using Liquibase adds complexity. But in practice, it actually reduces complexity. No more guesswork. No more broken SQL files. No more “It worked on my machine.”

Instead, you get:

A single source of truth.
Audit history of every change.
Easy rollbacks and repeatable deploys.

Once you use it on a few projects, it becomes second nature.

Conclusion

Liquibase is like the superhero sidekick you didn’t know you needed. It helps you:

Track database changes.
Apply them in a consistent way.
Roll them back when things go sideways.
Work better with your team and CI/CD pipelines.

If you’re a DB Admin tired of manual SQL chaos, it’s worth giving Liquibase a try. The mux-sql project shows just how clean and simple a YAML-based changelog can be. You’ve already got the skills - Liquibase just helps you use them smarter. So go ahead - set up that liquibase.yml, commit it to Git, and start managing your database like a boss.

❓ FAQs

1. Do I need to know Java to use Liquibase?

Nope! Liquibase is built in Java, but you don’t need to write any Java code to use it. You just need the Java Runtime Environment (JRE) installed to run the Liquibase CLI. Everything else like - YAML, SQL, or XML changelogs is what you already know.

2. Can I use Liquibase with my existing database?

Yes. Liquibase can integrate with an existing database by using the generateChangeLog command to capture the current state. From there, you can start tracking future changes incrementally with changesets.

3. What if I accidentally apply the wrong changeset?

That’s where rollback comes in. If you’ve defined a rollback block inside the changeset, you can undo changes safely using a simple command like:

liquibase rollbackCount 1

Without a defined rollback, you’ll need to handle it manually—but Liquibase will still show you what was applied and when.

4. Can multiple developers work on the same changelog?

Yes, but with structure. Each developer should add their own changesets with unique ids and authors. Keeping changelogs in version control (like Git) and modularizing them with include files helps avoid merge conflicts.

Further Resources

Running WebAssembly with ContainerD + CRUN + WasmEdge

Animesh Pathak — Mon, 21 Apr 2025 11:30:00 +0000

WebAssembly (Wasm) isn’t just for the browser anymore. It’s conquering the cloud too — and if you're feeling adventurous, let's plug it into container runtimes like containerd, run it with crun, and power up workloads in Kubernetes like a boss. Oh, and yes — we'll even touch on KubeVirt to show Wasm's flexibility in a virtualized world.

🛠️ Step 1: Install WasmEdge (The Wasm Runtime Hero)

Let’s kick things off by installing WasmEdge — a blazing-fast Wasm runtime optimized for cloud-native.

curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash
source $HOME/.wasmedge/env

✅ Verify Installation

wasmedge --version

Expected output:

wasmedge version 0.13.5

Now that you’re equipped with Wasm superpowers, let’s bring in the container orchestration party.

🧱 Step 2: Set Up ContainerD, CRUN, and Kubernetes

One-liner to install everything you need:

wget -qO- https://raw.githubusercontent.com/sonichigo/wasmedge-demo-example/main/install.sh | bash

This script handles:

Installing containerd
Configuring crun as the runtime
Patching containerd for Wasm support
Setting up a local Kubernetes cluster

Expected terminal logs include:

> Installing ContainerD and CRUN
<==============================>
...
Local Kubernetes cluster is running. Press Ctrl-C to shut it down.

Boom. That’s your Wasm-ready k8s cluster firing up 🎉

☁️ Step 3: Run a Wasm Container in Kubernetes

Switch into Kubernetes source and set up your config:

cd kubernetes && git checkout v1.22.4

export KUBERNETES_PROVIDER=local

sudo cluster/kubectl.sh config set-cluster local --server=https://localhost:6443 --certificate-authority=/var/run/kubernetes/server-ca.crt
sudo cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt
sudo cluster/kubectl.sh config set-context local --cluster=local --user=myself
sudo cluster/kubectl.sh

Check cluster status:

sudo cluster/kubectl.sh cluster-info

You should see your cluster nodes happily registered.

🌐 Step 4: Deploy a WebAssembly HTTP Service

Time to run a Wasm image in the cluster!

sudo cluster/kubectl.sh run --restart=Never http-server \
  --image=wasmedge/example-wasi-http:latest \
  --annotations="module.wasm.image/variant=compat-smart" \
  --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork": true}}'

Then hit it with:

curl -d "name=WasmEdge" -X POST http://127.0.0.1:1234

Expected output:

echo: name=WasmEdge

🥳 Success! You just ran a Wasm container natively in Kubernetes.

🧪 Bonus: Run This on KubeVirt!

Want to get even fancier? Try this in a KubeVirt virtualized environment. Since KubeVirt can run Kubernetes inside virtual machines, you can embed this Wasm-ready containerd setup inside those VMs — making it super versatile for hybrid environments and edge deployments.

Steps are similar, but inside a KubeVirt VM with Ubuntu or Fedora base image. After that, follow this same guide within that VM and enjoy full Wasm-k8s magic, powered by KubeVirt's virtualization layer.

3 Ways to Run WASM with OCI & Container Runtimes

There’s more than one way to cook this goose. Here's a breakdown of the 3 main approaches:

🧩 With `containerd-shim` (runwasi)

Detects Wasm images via target platform (wasm32)
Uses runwasi for Wasm, runc for regular containers
Backed by Docker, Microsoft
Powering Docker+WASM preview releases

⚙️ Option #2: With `crun`

A C-based OCI runtime (from Red Hat)
Detects Wasm via annotations (module.wasm.image/variant)
Supports full k8s stack: CRI-O, containerd, Podman, kind, microk8s

🦀 Option #3: With `youki`

A Rust-based OCI runtime
Also annotation-based detection
Can power CRI-O, containerd, Podman, kind, microk8s, and k8s

All of these can be visualized via their respective integration diagrams — worth including one if you're making this into a slide deck or dev talk!

🔚 Final Thoughts

WebAssembly isn’t the future - it’s the present. With WasmEdge, CRUN, and Kubernetes (even in KubeVirt), we now have the flexibility to run lightweight, fast, and secure applications anywhere. Whether you're targeting the cloud, the edge, or somewhere in between — you’re set up for success.

FAQs

1. Why use Wasm instead of Linux containers?

Wasm provides faster startup, smaller size, and better isolation — ideal for microservices and edge computing.

2. Do I need to change my Kubernetes setup to run Wasm?

Nope! With runtimes like crun or youki and proper annotations, it plugs right into your existing Kubernetes flow.

3. What languages can I use to build Wasm apps?

Rust, Go (with TinyGo), C/C++, Python (via Pyodide), and even JavaScript!

4. Can I run Wasm apps alongside Linux containers?

Yes, mixed workloads are totally supported — just annotate your Wasm images and the runtime handles the rest.

5. How does this differ from running containers in Docker?

Docker (via containerd) supports Wasm via runwasi, but this approach goes deeper into Kubernetes and custom runtime integrations using crun/youki.

🔥 Google Launches Firebase Studio: A New Era for AI App Development

Animesh Pathak — Fri, 11 Apr 2025 10:11:18 +0000

Google has just introduced Firebase Studio, a revolutionary cloud-based development environment tailored for building full-stack AI applications. This new toolset seamlessly integrates with Firebase services and leverages Gemini AI, creating a smart, collaborative, and agentic workspace for developers, all accessible via the cloud.

🚀 What’s Firebase Studio All About?

Firebase Studio reimagines the development workflow, combining AI-driven tools with a visual interface to make app building faster, smarter, and more collaborative. Whether you're prototyping ideas or deploying production-ready apps, Firebase Studio covers it all - no switching between multiple platforms or environments.

🔑 Key Features at a Glance

Multimodal Prototyping: Build app prototypes using natural language, images, and even hand-drawn sketches. This makes it incredibly easy for developers to bring ideas to life, especially during early-stage brainstorming and MVP creation.
AI-Powered Development: Refine your application in real-time with an integrated AI assistant. The Gemini-powered chat experience helps you iterate quickly, answer questions, suggest code, and improve UX—all within the Studio.
Seamless Code + Visual Workflow: Firebase Studio bridges the gap between visual prototyping and hands-on coding. Developers can dive into code whenever needed without disrupting the visual flow—perfect for teams with diverse skill sets.
Live Preview on Multiple Devices: Preview your app across different screen sizes and devices instantly. This ensures responsiveness and design consistency from the get-go.
Effortless Deployment: Once your app is ready, publish it with a click using Firebase App Hosting. The integration cuts down manual steps and gets your product to users faster.
Built-in Real-Time Collaboration: Work on the same project with teammates in real-time. Whether it's pair programming, design reviews, or debugging, Firebase Studio supports seamless collaboration.

💡 Why It Matters

Firebase Studio isn't just another development tool—it’s a leap toward making AI app development more accessible and agile. With real-time collaboration, AI support, and end-to-end deployment tools baked in, it simplifies what used to be a fragmented and time-consuming process.

This launch positions Firebase Studio as a must-watch tool for devs working in the AI, startup, and rapid prototyping space. Whether you’re a solo founder, product engineer, or part of a large dev team, Firebase Studio offers a unified platform to build, iterate, and launch smarter.

👉 Ready to try it out?
Check out the official announcement and dive into Firebase Studio here.

Breaking Language Barriers with Azure OpenAI and Next.js

Animesh Pathak — Thu, 10 Apr 2025 07:38:24 +0000

Ever found yourself struggling to communicate in another language? Yeah, me too. That’s why I built Translate.AI - an AI-powered translation tool that makes breaking language barriers not just seamless but actually fun!

As a developer, I wanted something fast, accurate, and scalable, so I turned to Azure OpenAI for its powerful language models and Next.js for a slick, performant frontend. What started as a simple idea quickly turned into an exciting project, blending AI magic with modern web development.

Why Did I Create my own translator? 🤔

I’ve used plenty of translation tools, and let’s be real, some of them completely miss the mark when it comes to accuracy and context. You’ve probably seen translations that are technically correct but sound robotic or awkward. That’s because many tools struggle to grasp the nuances of language, idioms, and contextual meaning.

I wanted to build something smarter - a translation tool that doesn’t just translate words but understands intent and context. By leveraging the power of Azure OpenAI, I created Translate.AI, a fast, accurate, and context-aware translation tool that feels natural.

What Makes Translate.AI Special?

🧠 AI-Powered Smarts: No more weirdly structured sentences; Azure OpenAI keeps it natural and context-aware.
🌍 Multi-Language Support: Whether it’s Spanish, French, or Klingon (okay, not yet, but soon?), it’s got you covered.
⚡ Blazing Fast: Powered by Next.js API routes, making translations nearly instant.
🔌 Easy Integration: Works smoothly with other apps via API, your app can talk to the world effortlessly!

My Stack of Choice

Building Translate.AI required a robust and efficient tech stack. Here’s what I used:

Next.js: Handles server-side rendering (SSR) and API routes, making translations lightning-fast.
Azure OpenAI: The GPT-based engine that powers the AI translations.
Axios: Makes fetching data easy and efficient.
Keploy: Ensures my code is bug-free by handling testing and mocking API calls.

Why Next.js? 🚀

If you're building a modern web app that needs to be fast, scalable, and SEO-friendly, Next.js is the way to go. For Translate.AI, Next.js provided the perfect blend of server-side rendering (SSR) and API routes, ensuring that translations are lightning-fast and the site loads almost instantly.

Since Next.js is built on React, development was smooth, and I could use my favorite UI components without any hassle.

One of the biggest advantages of Next.js is its built-in SEO optimizations.When you’re building a tool that needs to be easily found on Google, having proper meta tags, structured data, and blazing-fast load speeds is a game-changer.

In short, Next.js made Translate.AI efficient, scalable, and search engine-friendly. What more could a dev ask for? 😎

Let’s Peek Under the Hood 🧐

Here’s a quick breakdown of how it processes translation requests:

Step 1: Handling the Request 📩

The API takes in three key parameters:

text: The text that needs to be translated.
sourceLang: The language it’s currently in.
targetLang: The language it needs to be translated into.

Step 2: Talking to Azure OpenAI 🤖

The request is structured like a conversation with the AI, ensuring context matters in translations. Once the request is received, it’s structured in a way that ensures accurate translations:

const payload = {
  messages: [{ 
    role: 'user', 
    content: `Translate the following text from ${sourceLang} to ${targetLang}:

"${text}"

Only provide the translated text without any additional commentary or explanation.`
  }],
  max_tokens: 300,
  temperature: 0.3,
  model: DEPLOYMENT_NAME
};

Setting temperature to 0.3 ensures translations remain precise and avoid unnecessary AI creativity.

Step 3: Sending Back the Magic ✨

Once Azure OpenAI processes the request, the translated text is extracted and sent back:

return NextResponse.json({
  originalText: text,
  translatedText,
  sourceLang,
  targetLang
});

Making Sure Project Ranks High on Google

No point in making an awesome tool if no one finds it, right? Here’s how I made sure Translate.AI is SEO-friendly:

1. Catchy Page Titles & Meta Descriptions

Keywords like AI-powered translation, Next.js translation API, and Azure OpenAI translator are sprinkled throughout.

2. Super Fast Load Speeds

Thanks to Next.js server-side rendering (SSR) and static generation (SSG), pages load almost instantly.

3. Mobile-Friendly FTW

Built with a mobile-first approach, because let’s face it - most people are on their phones.

4. Google-Friendly Schema Markup

Structured data helps Google show Translate.AI in rich search results.

5. Great Content & Backlinks

Blog posts (like this one!) and backlinks help boost authority and trust.

What’s Next for Translate.AI? 🔮

This is just the start! Here’s what’s coming next:

Voice Translation: Speak, and it translates real-time magic!
AI Context Learning: The more you use it, the smarter it gets.
Browser Extension: Translate anything while you browse.

6 AI Tools every developer must try

Animesh Pathak — Wed, 12 Jul 2023 08:39:01 +0000

The code editors or software in the development process integrate AI tools. This automates complex steps in the development process. Developers get real-time feedback on code quality through these AI tools. We have listed the best AI tools in 2023 based on their usability. AI tools every developer must use to stay ahead of the competition.

TabNine

With AI-driven code suggestions, TabNine is a hit in the developer's community. It leverages machine learning algorithms to offer context-aware predictions. Based on the developer's pattern of writing code, it suggests code completions. Some features of TabNine include:
It integrates with Integrated Development Environments (IDEs) like Visual Studio Code, IntelliJ, Sublime Text, and Atom.
It supports over 20+ programming languages, including C/C++, TypeScript, React, and more.
It Converts natural language description into functional code.
TabNine provides privacy and security features to your code.
It gives quality output in any development field, whether web, mobile, or data science.
You can connect your codes to repositories such as GitHub, GitLab, and more.
The AI tool suggests automatic code refactoring to maintain code consistency and reduce review iterations.

GitHub Copilot

GitHub and OpenAI collaborated to develop GitHub Copilot. This AI-powered coding tool auto-generates and auto-completes code snippets. Copilot uses OpenAI’s advanced GPT model to provide context-based predictions. Some features of GitHub Copilot include:
It generates code segments based on the description, patterns, and contexts.
It integrates with the preferred coding tools like IDEs or visual studio code.
The tool can test your code, select code to perform different actions, and review existing code.
It supports various programming languages, including Python, TypeScript, Ruby, and more.
Copilot allows developers to share their code in real time with other developers.
Developers can track the progress of projects, including code suggestions.
The integration with GitHub’s code editor speeds up the coding process.

Amazon CodeGuru

AI-driven code review tool developed and managed by Amazon Web Services(AWS). With the automated code review functionality, Amazon CodeGuru reviews pull requests in corresponding repositories. This allows developers to deliver quality software solutions and enhance resource efficiency. Some key features of CodeGuru include:
It utilizes machine learning algorithms to identify potential issues and suggest recommendations for code optimization.
Reviews code to identify bugs and security vulnerabilities.
It helps developers to speed up the development process by reducing manual code review and optimizing performance.
It integrates with the preferred coding tools like IDEs through plugins and extensions.
CodeGuru provides real-time feedback and code suggestions to improve code quality.
The performance profiling feature helps developers to find and fix performance issues.

DeepCode

This AI-driven code review tool identifies potential coding errors and suggests improvements. Using DeepCode, developers tend to write cleaner code and improve coding standards. Some key features include:
It leverages machine learning to analyze code, spot bugs, and clean them up.
DeepCode supports almost all programming languages and is quick at identifying errors.
It is an independent platform or can integrate with the preferred code editors.
Developers can share, review and receive feedback on their code among the team.

IntelliCode

IntelliCode is an AI-powered coding tool by Visual Studio. Developers prefer it due to its context-specific code suggestions. During coding, IntelliCode identifies common coding tasks and suggests efficient action. Some key features of IntelliCode include:
It is a cloud-based tool supporting various programming languages, including Python, Kotlin, Ruby, Swift and more.
Through extensions and plugins, it can support additional programming languages.
IntelliCode leverages machine learning algorithms to provide code suggestions related to contexts.
Developers can share code across multiple contributors to get valuable recommendations.

Keploy

Keploy is an open-source, end-to-end (E2E) testing toolkit for developers. It creates test cases and data mocks/stubs by recording API calls, database queries, etc., making releases faster and more reliable.
Keploy works by being added as a middleware to your application. It captures and replays all network interaction served to the application from any source. This allows Keploy to generate test cases for all of your API endpoints, including those that are not explicitly tested by your unit tests. This can help you to identify and fix bugs that would otherwise go undetected.
Keploy can create data mocks/stubs for your APIs, which can help you to isolate your tests and make them more reliable. It can automatically compare test cases generated from previously collected traffic against updated behaviour of your application, and bring any differences to your attention. This can help you to identify regressions in your production code early on.

Conclusion

With AI-powered tools, developers are coding smarter, not harder. Not only do developers save time and efficiency, but they also improve the quality and maintainability of software applications. Developers can unlock potential coding abilities and ensure quality code with increased efficiency.

From code completion, suggestion, and bug detection to code review assistance and automated testing, we have suggested the AI tools every developer must use.

In this blog post, we have covered the best AI tools of 2023 that assist developers throughout the development process. As AI advances, it is expected to change the viewpoint of the development process with its robust tools.

Forem: Animesh Pathak

How diffChangelog and Snapshots Work Together

The Schema Sync Problem

The Command That Powers Schema Sync

How diffChangelog Actually Works?

Step 1: Snapshot Creation

Step 2: Object Graph Comparison

Step 3: ChangeLog Generation

How I Use This for Schema Syncing?

1. Environment Alignment (Dev → Staging → Prod)

2. Drift Detection in CI

3. Legacy Database Onboarding

Important Practical Lessons

Snapshot Scope Matters

Not Every Difference Should Be Deployed

Snapshots Enable Determinism

Why This Matters in Database DevOps?

Final Thoughts

Observability for Databases in CI/CD

Why Observability Matters for Databases ?

Common Observability Challenges Unique to Databases

Adding Observability in Database CI/CD Pipelines

The Payoff: Faster, Safer Releases

Conclusion

Smarter Database DevOps with AI: From Changelogs to Intelligent Pipelines

Why Databases Lag Behind in DevOps

Where AI fits in?

Beyond Changelogs: Towards Intelligent Pipelines

Try It Out

[Boost]

Why Your Git Branching Strategy Is Breaking Your Database Deployments

Why Your Git Branching Strategy Is Breaking Your Database Deployments

🧠 The Better Approach: Trunk-Based GitOps for DBs

✅ A Better Way: Trunk-Based GitOps for Databases

🧰 Tools to Make It Work

💡 Conclusion

What’s Happening Inside Your Linux Kernel?

Why Should You Care? 🤔

What kernel functions we can trace?

1. do_execve: Process Launch Tracker 🚀

2. security_capable: Permission Checkpoint 🛡️

3. security_sb_mount: Filesystem Mount Auditor 🗂️

4. load_module: Kernel Code Gatekeeper 🧩

How Do We Trace These Functions?

💬 Final Thoughts

FAQs

1. What is do_execve, and why trace it?

2. What does security_capable check?

3. What is security_sb_mount, and why is it important?

4. How do kprobes attach hooks to kernel functions?

How to Effectively Vet Your Supply Chain for Optimal Performance

Understanding the Risk of Supply Chain Attacks

Beyond Traditional Scanning

Introducing vet: Policy-Driven Supply Chain Protection

Key Features

Installation and Setup

Integrating vet into CI/CD Workflows

Real-World Case Studies

Conclusion

FAQ’s

What policies can I define with vet?

How does vet obtain vulnerability data?

Can I scan transitive dependencies?

How do I integrate vet into my CI/CD pipeline?

Is vet extensible to custom metadata sources?

References -

How Liquibase Makes Life Easy for DB Admins

What is Liquibase?

Why Should You Care?

How Does It Work?

YAML + Liquibase: A Perfect Match made in heaven

Why use YAML?

A Real-World Example: Mux + PostgreSQL

CI/CD and Liquibase = New Power Duo

But what About Rollbacks?

Best Practices for DB Admins Using Liquibase

The Learning Curve? Not So Steep!

Conclusion

❓ FAQs

1. Do I need to know Java to use Liquibase?

1. `do_execve`: Process Launch Tracker 🚀

2. `security_capable`: Permission Checkpoint 🛡️

3. `security_sb_mount`: Filesystem Mount Auditor 🗂️

4. `load_module`: Kernel Code Gatekeeper 🧩

1. What is `do_execve`, and why trace it?

2. What does `security_capable` check?

3. What is `security_sb_mount`, and why is it important?

🧩 With `containerd-shim` (runwasi)

⚙️ Option #2: With `crun`

🦀 Option #3: With `youki`