Ruby on Rails Modernisierung für Schweizer Unternehmen

Rails Modernisierung in 3 Phasen

Eine erfolgreiche Modernisierung ist kein Big-Bang-Rewrite, sondern ein schrittweiser, kontrollierter Prozess. Unser Vorgehen unterteilt die Arbeit in drei klar abgegrenzte Phasen, die jede für sich messbaren Geschäftswert liefern.

Phase 1: Audit & Stabilisierung

Bevor wir eine einzige Zeile Code anfassen, schaffen wir Sicherheit. Wir containerisieren die bestehende Anwendung mit Docker, um eine reproduzierbare Entwicklungsumgebung herzustellen. Wir messen die Testabdeckung mit SimpleCov und identifizieren die kritischsten Code-Pfade ohne Testschutz. Wir profilieren die Anwendung in Produktion (Scout APM, rack-mini-profiler), um die echten Performance-Bottlenecks zu finden, nicht die vermuteten.

Synthetic Engineering Context: SimpleCov-Schwelle in CI

# spec/spec_helper.rb
require 'simplecov'
SimpleCov.start 'rails' do
  add_group 'Services', 'app/services'
  add_group 'Background Jobs', 'app/jobs'
  minimum_coverage 70 # Anfangsschwelle für Legacy-Apps
  minimum_coverage_by_file 50
end

# .github/workflows/ci.yml
- name: Run tests with coverage gate
  run: |
    bundle exec rspec
    # SimpleCov gibt Exit-Code 1 zurück, wenn Schwelle unterschritten

Phase 2: Inkrementelle Upgrades

Wir überspringen niemals Rails-Major-Versionen. Stattdessen nutzen wir das next_rails-Gem für einen Dual-Boot-Ansatz: Die Anwendung läuft gleichzeitig unter der alten und neuen Rails-Version. Tests werden gegen beide Versionen ausgeführt. Deprecation Warnings werden behoben, bevor die Migration finalisiert wird. So upgraden wir typischerweise 4.2 → 5.2 → 6.1 → 7.x in separaten, jederzeit zurückrollbaren Schritten.

Synthetic Engineering Context: Dual-Boot mit next_rails

# Gemfile
gem 'next_rails', group: :development

if ENV['NEXT_RAILS']
  gem 'rails', '7.0.8'
else
  gem 'rails', '6.1.7'
end

# Bash: Beide Versionen installieren
$ bundle install
$ NEXT_RAILS=1 bundle install

# Tests gegen beide Versionen
$ bundle exec rspec
$ NEXT_RAILS=1 bundle exec rspec

# Production läuft weiter mit alter Version,
# Staging mit neuer Version. Wechsel erst nach grünem CI.

Phase 3: Refactoring & Architekturverbesserung

Nach erfolgreichem Upgrade beginnt die nachhaltige Verbesserung. Fat Controllers werden in Service Objects extrahiert. N+1-Queries werden mit includes, preload und Counter-Caches eliminiert. Veraltete Background-Job-Frameworks (DelayedJob) werden durch Sidekiq ersetzt. Jede Refactoring-Maßnahme wird durch Tests abgesichert, die bereits in Phase 1 entstanden sind.

Synthetic Engineering Context: Service Object Pattern

# Vorher: Fat Controller (45 Zeilen create-Action)
class OrdersController < ApplicationController
  def create
    # 45 Zeilen mit Validierung, Stripe-Aufruf, E-Mail-Versand,
    # Inventory-Update, Loyalty-Punkten und Slack-Notification
  end
end

# Nachher: Service Object kapselt Geschäftslogik
# app/services/orders/place_order.rb
module Orders
  class PlaceOrder
    Result = Struct.new(:success?, :order, :errors, keyword_init: true)

    def initialize(user:, params:)
      @user = user
      @params = params
    end

    def call
      ActiveRecord::Base.transaction do
        order = build_order
        return failure(order) unless order.save
        charge_payment(order)
        notify_warehouse(order)
        award_loyalty_points(order)
        Result.new(success?: true, order: order)
      end
    rescue Stripe::CardError => e
      Result.new(success?: false, errors: [e.message])
    end

    # ... private methods
  end
end

# Controller schrumpft auf 7 Zeilen
class OrdersController < ApplicationController
  def create
    result = Orders::PlaceOrder.new(user: current_user, params: order_params).call
    if result.success?
      redirect_to result.order, notice: 'Bestellung erfolgreich'
    else
      render :new, status: :unprocessable_entity
    end
  end
end