The Art of Iteration: Managing Provisory Changes in CRM v2 Development

Starting a v2 rewrite is exciting, but it also comes with the significant challenge of managing code that isn't quite final. In the Seba-fernandez/CRM-de-Alquileres-de-vajilla project, we're deep into crafting v2 for our rental crockery CRM, aiming for enhanced capabilities and a more robust user experience.

The Situation

Our goal with v2 is ambitious: a complete overhaul of key functionalities within our CRM. This process inherently involves a period of flux, where many changes are experimental, incomplete, or marked as "provisory." As indicated by recent commits like "cambios provisorios de v2, commit 3 de 5," we are actively engaging in iterative development. The challenge is maintaining stability, keeping the codebase clean, and ensuring that these temporary states don't derail our progress or introduce unforeseen bugs into the existing system.

The Descent

The initial phases of a v2 rewrite, especially when dealing with frequent "provisory changes," can quickly become chaotic. Without a clear strategy, temporary solutions accumulate, branches diverge wildly, and the technical debt grows silently. It's easy to lose track of which "provisory" component belongs to which stage of the overhaul, making it difficult to merge, test, or even roll back effectively. This scattered approach often leads to development bottlenecks and a fear of integrating new features too early.

The Wake-Up Call

We realized that merely making "provisory changes" without a systematic approach was unsustainable. To ensure a smooth transition to v2 and avoid a messy codebase, we needed to establish clear guidelines for how these iterative changes are managed. The goal was to transform temporary work into structured, manageable steps rather than isolated experiments.

What We Changed

To better handle the iterative nature of v2 development and its "provisory changes," we implemented several key practices:

1. Modular Development: We broke down v2 features into small, independent React components. Using Emotion for styling allowed us to encapsulate styles with components, making individual "provisory" features easier to isolate, develop, and integrate without affecting other parts of the application.

2. Clear Commit Hygiene: Even for work labeled "provisory," we enforced clear and descriptive commit messages. This ensures that each commit, like "commit 3 of 5," accurately reflects its purpose and stage of completeness, aiding in better tracking and easier rollbacks if needed.

3. Feature Flagging: To manage the progressive rollout of v2 features, we adopted a feature flagging strategy. This allows us to deploy "provisory" components to production in an inactive state, enabling us to test thoroughly and activate features for specific user groups or environments without a full redeployment. A service like Supabase could be used to manage these configuration flags.

4. Pipeline Pattern Thinking: We began to view the v2 rollout not as a single event, but as a series of staged releases. Each "provisory change" is considered a step in a larger, continuous delivery pipeline, ensuring incremental progress and reducing the risk of large, disruptive deployments.

Here's a simplified example of how a React component might use a feature flag:

import React from 'react';

// Imagine this comes from a configuration service like Supabase
const featureFlags = {
  enableV2Dashboard: true,
  enableNewBookingFlow: false,
};

const OldDashboard = () => (<div>Old Dashboard Content</div>);
const V2Dashboard = () => (<div>New & Improved V2 Dashboard!</div>);

const AppDashboard = () => {
  if (featureFlags.enableV2Dashboard) {
    return <V2Dashboard />;
  }
  return <OldDashboard />;
};

export default AppDashboard;

This code snippet demonstrates how enableV2Dashboard acts as a toggle, allowing us to conditionally render either the OldDashboard or the V2Dashboard. This separation ensures that v2 features can be developed and deployed alongside existing code without being immediately exposed to all users.

The Technical Lesson

"Provisory changes" are an inevitable and healthy part of large-scale development, especially during a v2 refactor. The key lesson is to not shy away from them but to manage them with intention. By structuring our development around modularity (React, Emotion), disciplined commit practices, and strategic feature flagging (Supabase), we transform temporary work into deliberate, reversible steps. This approach fosters a more predictable and less stressful development cycle.

The Takeaway

For any v2 effort or significant feature overhaul, plan for the "provisory." Structure your code for modularity, leverage feature flags for controlled rollouts, and uphold robust commit hygiene. This disciplined approach converts temporary work into a series of stepping stones, leading to a robust v2 release rather than a chaotic scramble.

Generated with Gitvlg.com