Finn Ships Rails Monolith 200 Times Daily Using AI Code Approvals

Ruby on Rails

Limiting automated code approvals to 150 lines stops agent-generated bloat and forces developers into smaller pull requests, cutting revert rates to 0.5% across 200 daily deployments.

AI-assisted summary of Shipping is your heartbeat: Rails in the agentic era - Ryan Sherlock — original source. Check the original for full context.

Source published: 2026-10-01

Key ideas

Finn (formerly Intercom) deploys its 15-year-old, 5-million-line Rails monolith 200 to 250 times daily, serving peak traffic of 150,000 requests per second and pushing merged code to production in roughly five minutes. (3:00)
Using Shopify's Rotoscope to map method-level dependencies across 225,000 tests, Finn runs only the specifications relevant to changed files, slashing CI test execution from 7.5 minutes to under 3 minutes and using only 5% of full-suite compute. (8:02)
Finn's proprietary AI review agent 'Trick' evaluates PRs across five distinct dimensions, autonomously approving 40% of all pull requests with a 0.5% revert rate while cutting merge turnaround from 160 to 36 minutes. (37:12)
Enforcing a strict 150-line ceiling for automated PR approvals created an emergent socio-technical shift, prompting developers to decompose changes into atomic PRs averaging just 68 lines. (37:12)

Detailed notes

## Background This talk by Ryan Sherlock was published on YouTube by the Ruby on Rails channel on October 1, 2026, with editing and post-production sponsored by Shopify. According to the video description, the session explores how a 15-year-old, five-million-line Rails monolith safely ships over 200 times a day—reaching production traffic within five minutes of merging—through intelligent test selection, bounded automated PR approvals, and rapid deployment and recovery systems.

## TL;DR Ryan Sherlock, Infrastructure and Core Technologies Lead at Finn (formerly Intercom), details the engineering architecture and cultural mindset that allow a massive Ruby on Rails monolith handling 150,000 requests per second to deploy updates roughly every three minutes. To prevent their 225,000-test suite from taking 60 hours to run, the team uses Shopify's Rotoscope profiler for intelligent test selection alongside pre-compiled `bootsnap` and S3 schema caches, bringing test execution under three minutes and build times down to 53 seconds. Sherlock also explains how they manage the surge in AI-generated code via Muster, an internal deployment system that triggers automated five-version rollbacks within 6 to 7 minutes when business-level "heartbeat indicators" detect anomalies. Finally, he introduces "Trick," a proprietary multi-stage AI code review agent trained on historical feedback from top engineers that automatically approves 40% of pull requests (capped at 150 lines), slashing merge times from 160 to 36 minutes with a 0.5% revert rate.

## Atmosphere & style The talk carries a pragmatic, fast-paced, and candid engineering tone, blending deep infrastructure metrics with dry, self-aware humor. Sherlock speaks with the grounded confidence of a practitioner sharing battle-tested lessons—Poking fun at DHH's keynote, comparing compliance audits to legal TV tropes, and affectionately mocking legacy internal UIs and early AI review outputs that read like "love letters to your code." The narrative arc moves from the daunting scale of a 15-year-old monolith to a reassuring sense of mastery, making the audience feel the invigorating pulse of an engineering culture where shipping is effortless, immediate, and fearless.

## Bulletin - [03:00](https://www.youtube.com/watch?v=EBJF55TyCVY&t=180s) Finn (formerly Intercom) deploys its 15-year-old, 5-million-line Rails monolith 200 to 250 times daily, serving peak traffic of 150,000 requests per second and pushing merged code to production in roughly five minutes. - [08:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=482s) Using Shopify's Rotoscope to map method-level dependencies across 225,000 tests, Finn runs only the specifications relevant to changed files, slashing CI test execution from 7.5 minutes to under 3 minutes and using only 5% of full-suite compute. - [37:12](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2232s) Finn's proprietary AI review agent 'Trick' evaluates PRs across five distinct dimensions, autonomously approving 40% of all pull requests with a 0.5% revert rate while cutting merge turnaround from 160 to 36 minutes. - [37:12](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2232s) Enforcing a strict 150-line ceiling for automated PR approvals created an emergent socio-technical shift, prompting developers to decompose changes into atomic PRs averaging just 68 lines.

## Key takeaways - [00:11](https://www.youtube.com/watch?v=EBJF55TyCVY&t=11s) Software value is realized only when code reaches production customers; every prior stage represents accumulated assumptions and unvalidated work. - [00:11](https://www.youtube.com/watch?v=EBJF55TyCVY&t=11s) Following a rapid pivot to customer service AI agents post-ChatGPT, the company rebranded to Finn and was acquired by Salesforce while operating a lean core stack of Rails, MySQL, Elasticsearch, and React. - [03:00](https://www.youtube.com/watch?v=EBJF55TyCVY&t=180s) Abandoning release trains in favor of continuous merges allows changes to reach production within five minutes, resulting in backend deploys roughly every three minutes. - [08:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=482s) To manage 225,000 test specs that would take 60 hours sequentially, Finn repurposes Shopify's Rotoscope profiler to build dynamic dependency mappings updated every 30 minutes. - [11:48](https://www.youtube.com/watch?v=EBJF55TyCVY&t=708s) Selective test execution reduced PR suite run times to under three minutes while consuming roughly 5% of the compute required for full test runs. - [14:04](https://www.youtube.com/watch?v=EBJF55TyCVY&t=844s) CI performance is maintained by grouping test parallelization by execution duration rather than file type, precompiling bootsnap caches, and caching database schemas in S3. - [19:06](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1146s) Build pipelines were compressed from 4.5 minutes to 53 seconds by consolidating deploy targets, eliminating unnecessary test artifact packing, and resolving a long-standing asset caching bug. - [24:32](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1472s) Business-level 'heartbeat indicators' monitor core customer interactions, triggering automated 5-version rollbacks that recover production health in 6 to 7 minutes without human intervention. - [27:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1622s) Finn rejects tiering deployments by perceived risk, treating every change as high-risk by default and subjecting all PRs to identical automated validation baselines. - [28:43](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1723s) Internal AI code reviewer 'Trick' breaks pull request evaluation into five stages—Problem Statement, Goal, Safety, Logic, and Codebase Practices—distilled from historical senior engineer reviews. - [34:51](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2091s) Automated approval requires strict bounded authority, capping PR size at 150 meaningful lines and blocking changes with detected race conditions or security concerns. - [36:19](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2179s) Compliance rules mandate human-in-the-loop accountability and prohibit autonomous agent loops where an AI approves another AI's pull request without oversight. - [37:12](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2232s) Automating PR approvals reduced median cycle time from 160 minutes to 36 minutes and resulted in a 0.5% revert rate, a tenfold improvement over complex human-reviewed PRs. - [38:31](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2311s) Rapid, automated deployment guardrails counterintuitively improved codebase quality and reduced incidents, proving that high shipping velocity prevents architectural decay rather than causing a 'big ball of mud.'

## Detailed walkthrough ### [00:11](https://www.youtube.com/watch?v=EBJF55TyCVY&t=11s) The Heartbeat of Shipping in the Agentic Era

Ryan Sherlock opens the session in Austin by setting the stage for how a massive, 15-year-old Ruby on Rails monolith containing 5 million lines of code manages to ship roughly 200 times a day—often pushing code into production a mere five minutes after a merge. Reflecting on DHH’s opening keynote about spending five hours recording a podcast in Austin, Ryan humorously notes that he listened to it and will unapologetically keep using the word "automation." The philosophical cornerstone of their engineering culture traces back to a blog post written 13 years prior by Des Traynor, Intercom's second-ever employee and current CTO, who built Intercom's original shipping system. The core thesis is that software value is only realized when it actually reaches customers; everything before that is just an expensive accumulation of hard work and assumptions. This continuous delivery mindset shapes not just how they build products, but how the entire company operates under a guiding loop: every change starts with a hypothesis (take an action), production provides useful evidence, you learn something new, and your next change incorporates those insights.

As the Infrastructure and Core Technologies Lead at Finn (formerly Intercom), Ryan explains that they deliberately rely on a relatively small, tightly-mastered technology stack of about ten core tools: Ruby on Rails, MySQL, Elasticsearch, and React, alongside owning the underlying infrastructure that runs them. Founded in 2011 to help clients deliver exceptional customer experiences, the company underwent a massive transformation when ChatGPT emerged. In roughly a single weekend, they completely pivoted their strategy to build customer service AI agents. Their flagship AI agent, Finn, became such a massive success that they rebranded the entire company around it five months prior, culminating in their acquisition by Salesforce just two weeks before the talk.

- **Core Tech Stack:** Ruby on Rails, MySQL, Elasticsearch, React (~10 core technologies total). - **Company Evolution:** Founded in 2011 as Intercom; pivoted over a single weekend to AI agents post-ChatGPT; rebranded to Finn; acquired by Salesforce two weeks prior to the talk.

---

[03:00](https://www.youtube.com/watch?v=EBJF55TyCVY&t=180s) Scale, Velocity, and the Zero-Release-Train Culture

Operating at scale, Finn runs a fully integrated Rails architecture on Edge browser versions, complete with an automated Slack notification every Tuesday where a designated engineer handles the weekly Edge upgrade. At peak operation, the system handles around 150,000 requests per second—translating to roughly 100,000 asynchronous requests, millions of database queries, and tens of millions of cache lookups. When Ryan joined in 2016, releases happened about every 30 minutes. Looking at their deployment charts, a modest uptick began in December when Opus 4.5 dropped, but after Christmas, the pressure intensified dramatically, pushing deployment rates to roughly 200 to 250 times a day when factoring in rollbacks or fresh Rails application builds.

```mermaid flowchart TD subgraph Scale and Velocity A["150k Requests/sec"] --> B["100k Asynchronous"] B --> C["Millions of DB Queries"] C --> D["Tens of Millions of Cache Lookups"] end subgraph Deployment Loop E["Developer / Agent Merge"] --> F["Production Deploy (~5 mins)"] F --> G["~200-250 Deploys Daily"] end

style A fill:#f9f,stroke:#333,stroke-width:2px style G fill:#bbf,stroke:#333,stroke-width:2px

accTitle: Finn Scale and Deployment Loop Architecture accDescr: Flowchart illustrating request scaling metrics on the left leading into the rapid 200-plus daily merge and deployment loop on the right. ```

There are no "release trains" for engineers and developers at Finn. When you click "merge" on an approved pull request, it hits production in about five minutes, directly impacting hundreds of thousands of customer support agents and millions of end-users, resulting in a backend update roughly every three minutes. This relentless pace instills a company-wide sense of urgency that flows from engineering all the way to legal and financial departments: "When you want to do something, you do it, and you get immediate feedback." While clients naturally prize stability—as highlighted by a customer who remarked in disbelief during a bug call, "It seems like you're releasing updates while we're using your application"—Ryan calculates that every single second of downtime equates to roughly 50 hours of employee usage and hundreds of hours of end-user time. To maintain high availability without slowing down, they enforce strict rules: changes must be kept small (typically pulling in three PRs per deploy, representing 600 to 700 individual changes from a monthly pool of 250 unique Rails contributors), backed by rigorous test suites and code reviews, supported by deep production monitoring, and coupled with near-instantaneous rollback capabilities.

- **Traffic Peak:** 150,000 requests/second, ~100,000 async requests. - **Release Frequency:** ~200 to 250 deployments per day (backend update every ~3 minutes). - **SLA Evolution:** Shifted from 30-minute deploys in 2016, to a targeted 15-minute P75 SLA, down to sub-5-minute production merges today. - **Contributor Base:** 250 unique Rails contributors in the prior month making small, atomic pull requests.

---

[08:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=482s) Managing 225,000 Tests with Rotoscope

Walking through their CI/CD learning loop, Ryan focuses heavily on their test suite expansion and management strategies. When he joined back in 2016 when annual recurring revenue was around $60 to $70 million, the system maintained about 16,000 tests. Over the following year, that test suite doubled, and by August, an additional 25,000 tests were added. This explosive growth was partly fueled by AI agents: with models like Opus, the volume of generated comments tripled, and agents actively generated massive numbers of test specs. However, running sequentially, their current tally of 225,000 test specifications would take an staggering 60 hours to execute, whereas a typical pull request only modifies about four files.

To solve this bottleneck without sacrificing safety, Finn leverages **Rotoscope**, a high-performance method-profiling recorder built by Shopify. Although not originally designed for test selection, Finn adapted Rotoscope ingeniously: every morning at 5:00 AM, they run their entire test suite through Rotoscope to map out dependencies. For example, running specifications A, B, and C touches `conversation.rb`, while specification D touches `billing.rb`.

```mermaid flowchart LR subgraph Rotoscope Pipeline A["5:00 AM Full Suite Run"] --> B["Rotoscope Profiler"] B --> C["Mapping File Generation"] C --> D["30-Minute Incremental Updates"] end subgraph Test Selection E["PR modifies conversation.rb"] --> F["Run Only Specs A, B, C"] F --> G["Skip Irrelevant Spec D"] end

style A fill:#fcf,stroke:#333,stroke-width:2px style E fill:#cff,stroke:#333,stroke-width:2px

accTitle: Rotoscope Intelligent Test Selection Architecture accDescr: Flowchart showing the 5 AM Rotoscope profiling run generating dependency mappings, which allows PRs modifying specific files to execute only relevant test specs. ```

This mapping allows them to build an intelligent test-selection index: when a pull request modifies `conversation.rb`, the system executes *only* specifications A, B, and C, completely bypassing specification D. To eliminate risk, core workflow specifications and security-related tests are always executed unconditionally, and any changes to core guides bypass guesswork to trigger the full test suite. This mapping index is incrementally updated every 30 minutes, keeping the deployment pipeline blazing fast and safe.

[11:48](https://www.youtube.com/watch?v=EBJF55TyCVY&t=708s) Managing PR Test Selection and Incidents

Ryan explains how pull requests handle testing when updates occur. If a pull request was created based on an update from 30 minutes ago, there might be newer tests that haven't been run yet, so the system tests everything up to the next update. They added a skip slot where developers can add an empty commit, causing the system to run the full suite.

They sometimes encounter "deployment incidents" where three or four people work on a pull request, and all pass the Rotoscope test successfully, but right before production, another full test is triggered. If Rotoscope fails, it halts the pipeline, or there might be an issue with the merge queue. However, they built tools to show engineers exactly what to do to fix the situation in under 30 seconds.

- Reduced test suite run time from over 7.5 minutes to under 3 minutes. - The selected test suite consumes only about 5% of the computing resources required for a full run. - CI integration volume increased 8x during the period, making optimization critical to avoid massive cloud bills. - Flaky tests are treated as P1 (Priority 1) issues during the day, requiring immediate fixing by the on-call engineer or background agents.

[14:04](https://www.youtube.com/watch?v=EBJF55TyCVY&t=844s) Parallelizing Tests and Optimizing Boots

When running tests, files are not grouped by type but by duration. Every time a test runs, the system records the elapsed time and distributes runtime so each group has roughly the same duration. For a full test, about 1,400 workers run in parallel, whereas Rotoscope uses only as many containers as needed to keep the duration around 3 minutes.

Boots represent an ongoing cost every time a test suite or deployment runs. Since Rails 5.2, `bootsnap` has been a default gem that populates a lazily compiled instruction cache, which speeds up subsequent boots. They also pre-compile it during image creation so runners have a ready cache immediately.

- Schema cache is saved to an S3 file so processes fetch the latest schema directly rather than running expensive full-table queries on startup, preventing production blips. - A small optimization to SQL source location tracing in Ruby eliminated heavy object allocation across hundreds of stack trace rows, speeding it up 10x and saving 20% of CI runtime. - The golden rule: "Stop doing static work and optimize high-frequency work."

[19:06](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1146s) Streamlining Builds and Eliminating Artifact Bloat

Moving to the build phase, Ryan discusses how they used to build six deployable units—historical tech debt accumulated over years. They built for two architectures across three regions. One x86 architecture was dedicated exclusively to a PDF generation project that a new engineer was assigned to review, which they ultimately canceled and replaced with a simpler solution.

They gradually reduced this to three regions, and eventually to a single server setup, which drastically reduced flaky failures caused by multiplying parallel build steps. They also discovered they were shipping spec nodes and bin nodes to every application instance—translating to packing and unpacking files 500,000 times a day—and promptly deleted the unnecessary files.

- A Tailwind CSS upgrade bug had broken production asset caching silently for five years, costing two minutes per build until caught. - Build execution time dropped from 4.5 minutes down to 53 seconds simply through observation, profiling, monitoring, and eliminating redundant static work. - Quick verification checks run in parallel with tests to verify connections to critical infrastructure and run security scans.

[22:29](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1349s) Deploying Across Thousands of EC2 Servers

Deploying across thousands of EC2 servers involves uploading the release artifact to S3 and using AWS Systems Manager (SSM) to ping all servers, notifying them of a new version to download and spin up. Rotating processes takes about 3 to 4 minutes.

- The system preserves the previous four versions of the application locally on each server for fast rollbacks and recovery.

[22:59](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1379s) The Muster Internal Management System and Deployment Metrics

The internal system that drives their deployment operations is named Muster. Dara, their Chief Technology Officer, initiated work on this project 15 years ago. While the current user interface is affectionately described as something only a parent could love, an incoming designer will soon focus on upgrading the user experience to address historical user errors caused by a lack of clarity.

Performance metrics remain a core pillar of their operation, reinforcing team accountability and transparency for engineers. Highlighting the breakneck speed of their workflow, the speaker shares a recent comment from an engineer who joked: "Man, we're shipping updates so fast I can't even make coffee when I click the merge button." They maintain a rigid deployment window of 11 minutes across five daily deployments, treating production not as a final destination, but as a stepping stone that directly informs subsequent customer interactions and iterative changes.

[24:32](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1472s) Heartbeat Indicators, Incident Recovery, and Automated Rollbacks

To catch issues beyond basic system health, the team relies on "heartbeat indicators" to monitor actual business outcomes. For instance, Finn's core mission is enabling customers to hold productive dialogues with their end-users—tracked via high-volume metrics on inbox navigation and support conversations. On August 25, an engineer deployed a faulty query that slipped into production, triggering an alarm. The team currently enforces a two-minute quiet period before sounding alarms to prevent false positives, down from an earlier 30-second threshold, with hopes of compressing it further to one minute in the near future.

An alarm immediately generates an incident report, pages the incident commander and engineering team, and triggers an automated rollback. Because their changes are kept intentionally granular, rollbacks are designed to be completely safe: instead of reverting to a stale state from two or four hours prior (which might strand user interface state), the system rolls back up to five versions—covering roughly the previous 20 minutes.

```mermaid flowchart LR subgraph Incident Response A["Faulty Query Deployed"] --> B["2-Minute Alarm Threshold"] B --> C["Automated Page & Incident Report"] C --> D["Automated Rollback (Last 5 Versions / ~20 mins)"] D --> E["Fully Automated Recovery (6-7 mins)"] end accTitle: Automated Incident Recovery Flow accDescr: Flowchart showing the automated incident detection and recovery pipeline from faulty deployment to automated rollback and recovery. ```

This fully automated recovery happens deterministically without human intervention, resolving incidents in 6 to 7 minutes. By comparison, similar incidents 4 to 5 years ago took 11 to 12 minutes due to manual discovery, slower manual rollbacks, and cumbersome coordination.

[27:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1622s) Compliance Control Levels and the Rise of AI Code Generation

Discussing compliance controls with an auditor prompted a humorous internal reflection on legal TV tropes—specifically the advice to "just answer what is asked" and "don't say anything silly." The speaker realized that rather than classifying deployments into low, medium, and high-risk tiers, they treat *every single change* as high-risk by default until proven otherwise. Whether modifying button text in the settings page or redirecting the application to a new database, every change follows the exact same stringent baseline.

This uniform rigor relies on a two-minute review and approval window, robust automated testing, rapid smoke tests, fast progressive rollouts, and automatic rollbacks upon failure—applied universally regardless of risk level, author, or approver. This approach is critical in the current era: because code creation costs have plummeted, over 95% of pull requests have been fully automated for the past six months, driving a three-fold velocity increase over 16 months and a four-fold increase the previous week.

[28:43](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1723s) Transforming Code Review with Trick: The AI Review Agent

With soaring pull request velocity, traditional human code review quickly became a severe bottleneck. Reflecting on early AI review assistant experiments (reminiscent of asking Claude to review a GitHub pull request and receiving an overly long "love letter to your code" full of abstract praise alongside 12 unstructured, mostly unhelpful bullet points), engineers simply ignored the wall of text and defaulted to human reviews.

Rather than merely accelerating reviews, the goal was to elevate their quality. To achieve this, they built **Trick**, their proprietary review agent. Operating within a company of roughly 100 dedicated AI engineers collaborating across products, they applied their core technology stack to internal code reviews. Using Claude and Aider models, reviews are broken down into five distinct, independent evaluation stages:

- **Problem Statement**: Evaluates whether the pull request description articulates a clear, understandable problem, objective, and underlying hypothesis. - **Goal / Verification**: Validates whether the code strictly solves the stated problem without introducing extraneous functionality. - **Safety**: Checks modifications against specific repository rules and guidelines (e.g., distinguishing comment form edits from database or security setting changes). - **Logic**: The most resource-intensive phase, where the model analyzes the code specifically for bugs. - **Codebase Practices**: Enforces Ruby on Rails best practices, accommodating historical modifications and PlanetScale database integration patterns.

To overcome the historical lack of documented best practices, the team analyzed historical Snowflake data to identify the top 10 to 20 engineers per repository. By mining years of their past pull request feedback, they codified elite human review insights directly into Trick's evaluation rubric.

- Backed by an extensive reference dataset of 500,000 pull requests and a curated benchmark of 1,000 historical production-breaking changes, Trick provides automated approvals that surpass human-level review quality.

[34:51](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2091s) اختبارات التراجع وآلية التحقق التلقائي لطلبات السحب

يوضح رايان شيرلوك التحديات غير المتوقعة التي ظهرت عند تحديث نماذج الذكاء الاصطناعي المستخدمة في تدقيق ومراجعة الأكواد البرمجية؛ فمع الترقية إلى نموذج أحدث وأكثر تطوراً، تراجعت دقة النموذج في بعض الجوانب الفرعية، وبدأ في اختلاق مشكلات وهمية والاعتراض على تفاصيل لا غبار عليها في الكود. فرض هذا التحدي ضرورة إجراء اختبارات رجعية (Regression Testing) شاملة في كل مرة يتم فيها تغيير النموذج أو تعديل صياغة التوجيهات (Prompts)، وذلك بمقارنة مخرجاته مع كامل سجل الاختبارات والحالات السابقة لضمان عدم حدوث أي انتكاس في دقة اتخاذ القرار.

يعرض رايان مثالاً حياً لما يظهر فعلياً داخل تعليقات طلبات السحب (Pull Requests) على GitHub، مستشهداً بطلب سحب حقيقي أنشأه بنفسه لتحسين الأداء. يقوم نظام الفحص الآلي بمرحلة تحقق صارمة؛ ففي هذا المثال، رصد النظام حالة تضارب وتزامن (Race condition) في كتلة التحقق `ensure` وما شابهها، وبناءً على ذلك رفض منح الموافقة التلقائية. بالإضافة إلى ذلك، يفرض النظام فحصاً دقيقاً لعدد أسطر التعليمات البرمجية ذات المعنى (Meaningful lines of code)؛ حيث تم تحديد سقف صارم لا يتجاوز 150 سطراً في هذا المستودع للتأهل للموافقة الآلية. وإذا تجاوز التغيير هذا الحد أو فشل في أحد المعايير، يدرج النظام تعليقاً واضحاً يفيد بضرورة تدخل مراجع بشري لإكمال المراجعة.

```mermaid flowchart TD accTitle: مسار تدقيق طلب السحب الآلي accDescr: يوضح الرسم مسار فحص طلب السحب والتحقق من حجم الكود وخلوه من أخطاء التزامن قبل منح الموافقة التلقائية أو طلب تدخل بشري.

subgraph Evaluation["مرحلة التحقق الآلي"] PR["فتح طلب السحب"] --> SizeCheck{"حجم الكود <= 150 سطراً؟"} SizeCheck -->|"نعم"| SafeCheck{"خالٍ من أخطاء التزامن والعيوب؟"} SizeCheck -->|"لا (تجاوز الحد)"| HumanReview["طلب مراجع بشري"] SafeCheck -->|"رصد عيب برمجي"| AgentLoop["تنبيه الوكيل للإصلاح"] end

subgraph Resolution["المعالجة والاعتماد"] AgentLoop --> PR SafeCheck -->|"اجتياز كامل"| AutoApprove["موافقة آلية فورية"] end ```

[36:19](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2179s) الامتثال والمسؤولية: إجابة أسئلة المدققين والحلقات المغلقة للوكلاء

يتطرق الحديث إلى بناء حلقات عمل ذاتية بالكامل بين المطورين والوكلاء البرمجيين، حيث يعمل المهندس جنباً إلى جنب مع نموذج Claude الذي يراقب تنبيهات ومشكلات GitHub. فعندما يرصد النموذج تعليق النظام بوجود مشكلة تزامن، ينطلق الوكيل لإصلاح الخلل بشكل مستقل دون أي تدخل يدوي، وينشئ طلبات سحب جديدة ومحاولات دمج متتابعة حتى تجتاز كافة الفحوصات بنجاح.

أثار هذا النمط من العمل تساؤلات حذرة من جانب مدققي الامتثال والحوكمة (Auditors)، لكن إجابات الفريق كانت واضحة وقاطعة عبر مجموعة من الركائز الأساسية:

- **استقلالية المؤلف والمعتمد:** الحفاظ على مبدأ الفصل التام؛ فلا يُسمح إطلاقاً بأن يقوم وكيل ذكاء اصطناعي بإنشاء طلب سحب ثم يقوم وكيل ذكاء اصطناعي آخر بالموافقة عليه ودمجه دون إشراف. - **وجود العنصر البشري في الحلقة:** وجود إنسان في حلقة العمل لمعظم أنواع طلبات السحب، بحيث يقتصر دور النظام الآلي على جانب واحد من المعادلة حالياً. - **التوثيق الكامل بالأدلة:** تشغيل بيئات التكامل المستمر (CI)، واجتياز حزم الاختبارات بالكامل، والاحتفاظ بسجل تدقيق شامل وقابل للتتبع لكل إجراء. - **السلطة المحدودة (Bounded Authority):** قصر الموافقة التلقائية على مستودعات محددة جرى اختبارها والتأكد التام من استقرارها، مع الإبقاء على المسؤولية النهائية عاتقاً على العنصر البشري الذي يقود العملية، سواء كان يستخدم أدوات مثل Claude أو Codex.

[37:12](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2232s) النتائج والأرقام بعد الإطلاق: سرعة الدمج وانكماش حجم الأكواد

يكشف رايان عن الأثر التشغيلي الهائل الذي أحدثه إطلاق نظام الموافقة الآلية، مقارناً المقاييس السابقة بمؤشرات الأداء الحالية. فقد انخفض متوسط الوقت المستغرق من فتح طلب السحب ومراجعته وحتى دمجه نهائياً من 160 دقيقة في مسار المراجعة البشرية التقليدية إلى 36 دقيقة فقط عبر النظام الآلي. ورغم إشارته إلى أن المقارنة تتضمن تفاوتاً في طبيعة التغييرات لأن النظام يتعامل حالياً مع طلبات سحب أقل خطورة، إلا أن النتيجة تظل قفزة إنتاجية فارقة.

- **40% من إجمالي طلبات السحب** في الشركة أصبحت تحظى بموافقة واعتماد آلي بالكامل، مما يجعل موظفاً واحداً فقط كافياً لإتمام العملية. - **معدل التراجع (Revert Rate):** بلغت نسبة التراجع عن طلبات السحب المعتمدة آلياً 0.5% فقط (أي طلب تراجع واحد من بين كل 200 طلب سحب)، مقارنة بنسبة تتجاوز 5% في التغييرات التي يعتمدها المراجعون البشريون (مع الأخذ بالاعتبار تعامل البشر مع أكواد أكثر تعقيداً ومخاطرة). - **انكماش حجم طلبات السحب:** على عكس المخاوف الشائعة على الإنترنت من أن وكلاء الذكاء الاصطناعي سينتجون طلبات سحب عملاقة ومستحيلة المراجعة، حدث العكس تماماً بفعل التصميم الاجتماعي-التقني للنظام؛ فعندما أدرك المطورون أن الحد الأقصى للموافقة الآلية هو 150 سطراً، حفزهم ذلك على تجزئة أعمالهم إلى تغييرات صغيرة جداً لتسريع دمجها، مما خفض متوسط حجم طلب السحب إلى حوالي 68 سطراً من الأكواد البرمجية فقط.

[38:31](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2311s) التحديات المتبقية وفلسفة دورة النشر السريعة

رغم هذه النجاحات، لم تخلُ التجربة من مشكلات مفتوحة لا تزال قيد البحث؛ وفي مقدمتها تضخم حجم الاختبارات (Test Suite Bloat) وتراكم اختبارات متكررة أو غير ضرورية. يخصص الفريق حالياً عدداً من أكفأ مهندسيه لتنظيف حزم الاختبارات وضبطها، معتبرين أن هذا التضخم قد يكون جرس إنذار مبكر لظاهرة الانحراف المعماري (Architectural Drift).

يعترف رايان بصراحة بأنه لو سُئل قبل عام عن التداعيات المحتملة لهذا الكم الهائل من الأكواد والتغييرات المتسارعة، لكان رده: *"يا إلهي، سنحصل على كرة كبيرة من الطين"* ("a big ball of mud")، معبراً عن قلقه الشديد آنذاك. ولكن الواقع أثبت عكس ذلك تماماً؛ إذ انخفضت معدلات الحوادث والأعطال، وارتفعت جودة المنتج، وتقلصت المدة الزمنية الفاصلة بين ولادة فكرة الميزة الجديدة ووصولها إلى الإنتاج بين أيدي العملاء الفعليين.

تظل إحدى النقاط التقنية التي يسعى الفريق لتحسينها هي تقليص وقت استجابة الأسطول عند التراجع التلقائي (Fleet Restart / Rollback)، والذي يستغرق حالياً بين ثلاث إلى أربع دقائق. يبحث الفريق تطوير بدائل برمجية خاصة تتجاوز آليات خوادم الويب الحالية مثل Phusion Passenger وEinhorn لتمكين الإيقاف الفوري؛ ففي حالات انقطاع الخدمة أو تعطل التطبيق، لا يكترث المهندس بإنهاء العمليات بسلاسة بل يريد وقف الضرر على الفور.

يختتم رايان كلمته بالتأكيد على الفلسفة الجوهرية لدورة الإنتاج البرمجي: كل تغيير يبدأ بفرضية، تتبعه تجربة عملية، ثم تكشف بيئة الإنتاج عن السلوك الحقيقي للنظام وتقدم دروساً قيّمة يجب دمجها في التجربة التالية مباشرة. لذا، فإن الهدف الأسمى لفرق الهندسة هو جعل هذه الدورة تدور بأقصى سرعة وأمان ممكنين لتظل بمثابة "نبض القلب" المستمر للمؤسسة.

## Notable quotes > [03:00](https://www.youtube.com/watch?v=EBJF55TyCVY&t=180s) When you want to do something, you do it, and you get immediate feedback. — Ryan Sherlock

> [03:00](https://www.youtube.com/watch?v=EBJF55TyCVY&t=180s) It seems like you're releasing updates while we're using your application

> [14:04](https://www.youtube.com/watch?v=EBJF55TyCVY&t=844s) Stop doing static work and optimize high-frequency work. — Ryan Sherlock

> [22:59](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1379s) Man, we're shipping updates so fast I can't even make coffee when I click the merge button.

> [27:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1622s) just answer what is asked — Ryan Sherlock

> [27:02](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1622s) don't say anything silly — Ryan Sherlock

> [28:43](https://www.youtube.com/watch?v=EBJF55TyCVY&t=1723s) love letter to your code — Ryan Sherlock

> [38:31](https://www.youtube.com/watch?v=EBJF55TyCVY&t=2311s) a big ball of mud — Ryan Sherlock

## Mentioned Ryan Sherlock, David Heinemeier Hansson (DHH), Des Traynor, Intercom, Finn, Salesforce, Shopify, Ruby on Rails, MySQL, Elasticsearch, React, ChatGPT, Claude, Opus 4.5, Rotoscope, bootsnap, AWS, Amazon S3, AWS Systems Manager (SSM), Tailwind CSS, Muster, Dara, Trick, Aider, PlanetScale, Snowflake, GitHub, Codex, Phusion Passenger, Einhorn

## Video description How does a 15-year-old, five-million-line Rails monolith ship more than 200 times a day, reaching first production traffic about five minutes after merge? Ryan Sherlock breaks down the test selection, bounded automated PR approval, build, deployment and recovery systems that make speed safe, and why agent-driven development makes that shipping loop more important than ever.

Thank you Shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

[Source](https://www.youtube.com/watch?v=EBJF55TyCVY)

中文简报

Finn借助AI代码审批，实现Rails单体应用每日部署200次将自动代码审批限制在150行以内，有效遏制了AI智能体生成的代码膨胀，促使开发者提交更小的PR，从而在每日200次部署中将回退率降至0.5%。 Finn（前身为Intercom）基础设施与核心技术负责人Ryan Sherlock详细介绍了支撑其庞大Ruby on Rails单体应用的工程架构与文化理念——该应用每秒处理15万次请求，且大约每三分钟就能部署一次更新。为避免包含22.5万个测试的套件耗费60小时运行，团队采用Shopify的Rotoscope分析器进行智能测试筛选，并结合预编译的`bootsnap`和S3 schema缓存，将测试执行时间控制在3分钟以内，构建时间缩短至53秒。Sherlock还解释了他们如何通过内部部署系统Muster来应对AI生成代码的激增：当业务级“心跳指标”检测到异常时，该系统会在6到7分钟内自动触发跨五个版本的回滚。最后，他介绍了专有的多阶段AI代码审查智能体“Trick”。该智能体基于顶尖工程师的历史反馈进行训练，可自动批准40%的PR（上限为150行代码），在保持0.5%回退率的同时，将合并时间从160分钟大幅缩减至36分钟。 Finn（前身为Intercom）每天对其已有15年历史、包含500万行代码的Rails单体应用进行200至250次部署，在应对每秒15万次请求峰值流量的同时，仅需约五分钟即可将合并后的代码推送至生产环境。 (3:00) Finn利用Shopify的Rotoscope在22.5万个测试中映射方法级依赖关系，仅运行与变更文件相关的测试规范，从而将CI测试执行时间从7.5分钟缩短至3分钟以内，且仅消耗全量测试套件5%的算力。 (8:02) Finn专有的AI审查智能体“Trick”从五个不同维度评估PR，自主批准了40%的PR，回退率仅为0.5%，同时将合并周转时间从160分钟大幅缩短至36分钟。 (37:12) 对自动PR审批严格执行150行代码的上限，引发了社会技术层面的自发转变，促使开发者将变更拆分为平均仅68行的原子级PR。 (37:12)

Reading summary

Ryan Sherlock, Infrastructure and Core Technologies Lead at Finn, argues that software value is realized only when code reaches production, positioning continuous, sub-five-minute deployment cycles as an essential organizational feedback loop. Operating a 15-year-old, five-million-line Ruby on Rails monolith, Finn sustains this pace by pairing small atomic pull requests with automated test selection, aggressive build pruning, and automated recovery guardrails. High-Frequency Delivery and Zero Release Trains (0:11) Finn's engineering model is anchored in the continuous delivery philosophy framed 13 years ago by CTO Des Traynor: work prior to deployment represents accumulated assumptions rather than delivered customer value. Supported by a tightly controlled stack of roughly ten core technologies—principally Ruby on Rails, MySQL, Elasticsearch, and React—the company pivoted rapidly to customer service AI agents following ChatGPT's release, rebranding from Intercom to Finn before being acquired by Salesforce. At peak operation, the platform serves 150,000 requests per second, including 100,000 asynchronous jobs, while running on Edge browser versions upgraded weekly. To sustain velocity without release trains, approved pull requests reach production within roughly five minutes, totaling 200 to 250 deployments each day. Because Sherlock calculates that one second of downtime equates to roughly 50 hours of customer employee usage, the company enforces strict safeguards: batches are limited to small increments—typically three pull requests per deploy from a monthly pool of 250 Rails contributors—backed by immediate rollback mechanisms. Targeted Testing and Build Pipeline Optimization (8:02) As the platform expanded, its test suite surged from 16,000 tests in 2016 to 225,000 specifications, a volume that would require 60 hours to run sequentially. To eliminate CI bottlenecks, Finn adapted Shopify's Rotoscope profiler to run daily at 5:00 AM, mapping exact code execution dependencies and refreshing the index every 30 minutes. Pull requests modifying specific files run only the associated tests, while core workflow and security suites run unconditionally. This selective testing reduced suite run times from over 7.5 minutes to under 3 minutes, consuming only 5% of full-run compute resources despite an eight-fold surge in CI integration volume. Boots and builds were streamlined through targeted profiling. The team pre-compiles instruction caches using Bootsnap during image creation, caches database schemas in Amazon S3 to eliminate startup table queries, and optimized SQL stack-trace allocations to save 20% of CI runtime. Build times fell from 4.5 minutes to 53 seconds after consolidating multi-region, multi-architecture units into a unified server image and fixing a five-year-old Tailwind CSS asset caching bug. Heartbeat Monitoring and Automated Incident Recovery (24:32) Rather than categorizing pull requests into arbitrary risk tiers, Finn treats every change as high-risk by default. Compliance rests on standard requirements: automated testing, fast smoke tests, and progressive rollouts. Operational health is tracked via customer-centric 'heartbeat indicators,' such as inbox navigation and support conversations, rather than purely technical server uptime metrics. When a faulty deployment triggers an alarm, the system enforces a two-minute window to filter out transient false positives before paging an incident commander and initiating an automated rollback. Because changes are merged in small, granular batches, the rollback system deterministically reverts up to five release versions (representing roughly the prior 20 minutes of code). This automated recovery resolves incidents in six to seven minutes without manual engineering intervention, down from the 11 to 12 minutes required under historical manual discovery. Automating Code Review with Strict Guardrails (28:43) With code-generation models contributing to over 95% of pull requests over a six-month span, human code review became a critical bottleneck. In response, Finn developed Trick, an internal AI review agent powered by Claude and Aider. Trick evaluates pull requests across five structured criteria: problem statement clarity, verification against stated goals, safety guidelines, bug logic, and codebase conventions. Its evaluation rubric was built by analyzing historical review feedback from top engineers across 500,000 pull requests and benchmarked against 1,000 past production outages. To satisfy compliance and safety audits, the system maintains strict guardrails: autonomous agents cannot approve other agents' pull requests, a human must remain in the review loop for complex work, and automated approvals are capped at pull requests with no more than 150 meaningful lines of code. This size constraint incentivized engineers to break tasks into smaller units, reducing the average pull request size to 68 lines. Approximately 40% of all company pull requests are now approved automatically, cutting merge times from 160 minutes to 36 minutes and achieving a 0.5% revert rate, compared to over 5% for higher-risk human-reviewed pull requests. Sherlock notes ongoing operational challenges, particularly test suite bloat and the risk of architectural drift under rapid AI code generation. Additionally, the team is investigating custom process managers to replace Phusion Passenger and Einhorn, aiming to eliminate the current three- to four-minute fleet restart delay for instantaneous rollbacks during critical outages.

Source quotes

[3:00] Ryan Sherlock: When you want to do something, you do it, and you get immediate feedback. [3:00] It seems like you're releasing updates while we're using your application [14:04] Ryan Sherlock: Stop doing static work and optimize high-frequency work. [22:59] Man, we're shipping updates so fast I can't even make coffee when I click the merge button. [27:02] Ryan Sherlock: just answer what is asked [27:02] Ryan Sherlock: don't say anything silly [28:43] Ryan Sherlock: love letter to your code [38:31] Ryan Sherlock: a big ball of mud

Original transcript

[0:11] مساء الخير يا أوستن. [0:12] حسنًا. سنرى اليوم كيف [0:15] يتم شحن تطبيق Ruby on Rails [0:17] ضخم، عمره 15 عامًا، [0:19] يحتوي على 5 ملايين سطر [0:22] برمجي، حوالي 200 مرة [0:24] يوميًا. موضوع حديثنا [0:26] هو أن الشحن هو نبضك. [0:29] Rails في عصر الأتمتة. [0:32] ربما سمعتم في الكلمة [0:34] الافتتاحية DHH يتحدث [0:36] عن وجوده في أوستن [0:37] لمدة 5 ساعات لتسجيل [0:39] بودكاست. لقد استمعتُ [0:41] إلى ذلك البودكاست. [0:44] نعم، سأستخدم كلمة " [0:46] أتمتة" على أي حال. [0:49] تبدأ قصتنا اليوم بهذه [0:50] التدوينة. كتبها ديس [0:52] تراينور، الذي كان [0:54] ثاني أهم موظف في Intercom [0:56] وهو مديرنا التقني [0:57] الحالي. كانت مهمته [1:00] الأولى بناء نظام يسمح [1:03] لـ Intercom بشحن المنتجات [1:05] . لذا، العنوان الفرعي [1:08] هنا هو أن قيمة [1:09] البرمجيات لا تتحقق [1:10] إلا عند شحنها للعملاء [1:12] . قبل ذلك، هي مجرد [1:13] تراكم مكلف للعمل [1:15] الشاق والافتراضات. [1:17] كتب ديس هذه التدوينة [1:19] قبل 13 عامًا. كان ذلك [1:21] قبل وقت طويل من شيوع [1:23] مفهوم التسليم [1:24] المستمر، وهو أساسي [1:26] ليس فقط لكيفية بناء [1:28] المنتج، بل لكيفية [1:29] بناء الشركة نفسها. [1:31] لذا، يمكن تلخيص الأمر [1:33] في عدة نقاط. يبدأ كل [1:35] تغيير بفرضية. أي، قم [1:37] بتنفيذ خطوة ما. ثم، [1:39] يوفر الإنتاج أدلة [1:41] مفيدة. وهكذا، تتعلم [1:43] شيئًا جديدًا. ويجب أن [1:45] يتضمن التغيير التالي [1:47] تلك الأدلة. لذا، تقوم [1:49] بالخطوة التالية. [1:50] وسيشرح هذا الحديث [1:52] الآلية الكامنة وراء [1:53] ذلك، لأن مهمة فريقي [1:55] هي جعل هذه الدورة [1:57] بأسرع ما يمكن. أولًا، [2:00] أنا رايان شيرلوك، [2:01] قائد البنية التحتية [2:03] والتقنيات الأساسية [2:04] في شركة فين. نؤمن [2:05] بالبناء على مجموعة [2:07] صغيرة نسبيًا من [2:08] التقنيات التي نتقنها [2:09] جيدًا. مثل روبي أون [2:11] ريلز، وماي إس كيو إل، [2:12] وإيلاستيك سيرش، [2:13] ورياكت. هناك حوالي [2:14] عشر تقنيات من هذا [2:15] النوع. كما أننا نمتلك [2:17] في النهاية البنية [2:18] التحتية التي تشغلها. [2:19] من المفترض ألا يكون [2:21] لدي تقنية مفضلة، ولكن [2:22] بالطبع لدي تقنية [2:24] مفضلة. والآن، دعونا [2:26] نتحدث عن إنتركوم. [2:27] تأسست شركة Intercom عام [2:30] 2011 لمساعدة عملائنا [2:32] على تقديم تجارب عملاء [2:34] مميزة. وقد كان لتطور [2:37] الذكاء الاصطناعي أثر [2:38] كبير علينا. فعندما [2:40] ظهر ChatGPT، قمنا بتغيير [2:41] استراتيجية شركتنا [2:43] بالكامل خلال عطلة [2:44] نهاية أسبوع واحدة [2:45] تقريبًا لبناء وكلاء [2:47] خدمة عملاء. وقد حقق [2:48] فين، وكيل الذكاء [2:50] الاصطناعي الخاص بنا، [2:51] نجاحًا باهرًا، لدرجة [2:53] أننا قمنا بتغيير اسم [2:54] الشركة بالكامل قبل 5 [2:56] أشهر. وقبل أسبوعين، [2:57] استحوذت علينا Salesforce. [2:59] والآن، دعونا نتحدث عن [3:01] حجم أعمالنا وخلفية عن [3:03] كيفية تطويرها. نحن [3:05] نعتمد على بنية Rails [3:06] متكاملة. الجزء الأكبر [3:08] من كود الواجهة [3:08] الخلفية لدينا مبني [3:09] على هذه البنية. كما [3:10] أننا نستخدم متصفح Edge. [3:12] لذا، نتلقى رسالة [3:14] قصيرة على Slack كل [3:15] ثلاثاء، ومهمة أحد [3:17] الأشخاص هي الترقية [3:18] إلى Edge أسبوعيًا. في [3:20] ذروة العمل، نجري [3:21] حوالي 150,000 طلب في [3:23] الثانية، أي ما يعادل [3:25] حوالي 100,000 طلب غير [3:26] متزامن. هذا يعني [3:28] ملايين طلبات قواعد [3:29] البيانات وعشرات [3:30] الملايين من عمليات [3:31] الوصول إلى ذاكرة [3:32] التخزين المؤقت. هذا [3:37] هو معدل عمليات النشر [3:38] لدينا شهريًا. عندما [3:40] انضممتُ، كنا ننشر كل [3:42] 30 دقيقة تقريبًا، وكان [3:43] ذلك في عام 2016. إذا [3:45] نظرتَ إلى الرسم [3:46] البياني، ستلاحظ أن [3:47] المنطقة التي تبدأ [3:49] باللون الأحمر كانت في [3:50] ديسمبر من العام [3:52] الماضي، عندما صدر Opus [3:53] 4.5. بدأنا نلاحظ [3:54] ارتفاعًا في معدل [3:55] النشر، ولكن بعد عيد [3:56] الميلاد، ازداد الضغط [3:58] بشكل كبير. الآن، ننشر [3:59] حوالي 200 عملية نشر [4:01] يوميًا. في حال عدم [4:02] وجود أي مشاكل في [4:03] النشر، قد ننشر تطبيق [4:05] Rails جديدًا حوالي 250 [4:07] مرة. لذا، فإن وتيرة [4:09] النشر هي التي تحدد [4:11] آلية عمل Finn. بالنسبة [4:12] للمهندسين والمطورين، [4:14] ليس لدينا نظام "قطار [4:16] إصدار". فعندما تنقر [4:17] على "دمج" لطلب سحب [4:19] مُعتمد، يتم نشره في [4:20] بيئة الإنتاج خلال 5 [4:22] دقائق تقريبًا، ويصل [4:24] إلى مئات الآلاف من [4:25] موظفي دعم العملاء. [4:27] يُغيّر هذا الأمر [4:28] طريقة عمل Finn، ويرى [4:29] ملايين المستخدمين [4:30] النهائيين إصدارًا [4:31] مختلفًا من التطبيق. [4:33] لذا، نعم، هذا يعني [4:34] تحديثًا جديدًا [4:35] للواجهة الخلفية كل 3 [4:37] دقائق تقريبًا. وهذا [4:38] أمرٌ طريف. فوظيفتنا [4:41] كشركة هي بناء منتج [4:43] يستخدمه العملاء. [4:44] وتُعدّ وتيرة إصدار [4:46] المنتجات بمثابة نبض [4:47] الحياة لبقية أقسام [4:49] الشركة. لذا، فهي [4:50] تُرسّخ هذا الشعور [4:51] بالإلحاح الذي يُمكن [4:52] ملاحظته من قِبلنا [4:53] وصولًا إلى الإدارات [4:55] القانونية والمالية. [4:56] فعندما تُريد القيام [4:58] بشيء ما، تقوم به، [4:59] وتتلقى ردود فعل فورية [5:01] . وهذا ينطبق على [5:03] الشركة بأكملها. لذا، [5:06] قد تقول: "أوه، أنتم [5:07] تُصدرون 250 إصدارًا [5:09] يوميًا، هذا أمرٌ خطير [5:11] بالتأكيد". فعملاؤنا [5:12] يحتاجون إلى [5:13] الاستقرار قبل كل شيء. [5:15] على سبيل المثال، كنتُ [5:16] في مكالمة مع أحد [5:17] العملاء مؤخرًا، وقد [5:18] واجهوا عيبًا برمجيًا. [5:20] وكان من بين ما قالوه: " [5:21] يبدو أنكم تُصدرون [5:23] الإصدارات أثناء [5:24] استخدامنا لتطبيقكم". [5:26] هل هذا صحيح؟ قلت في [5:28] نفسي: يا إلهي، [5:29] انتظروا حتى نخبركم [5:30] بهذا. دفعتني هذه [5:32] المحادثة لكتابة [5:33] تدوينة، ثم ألهمتني [5:34] أيضًا لتقديم عرض [5:36] تقديمي كهذا في مؤتمر. [5:37] بعد إجراء الحسابات، [5:39] وجدت أن كل ثانية من [5:41] انقطاع الخدمة، ثانية [5:42] واحدة مثلاً، تعادل [5:44] حوالي 50 ساعة من [5:45] استخدام الموظفين [5:47] لبرنامج دعم العملاء، [5:49] ومئات الساعات من [5:50] استخدام المستخدمين [5:52] النهائيين لنظامنا. [5:53] لذا، كل ثانية مهمة [5:55] حقًا. لكن القدرة على [5:58] إطلاق التحديثات مع [5:59] الحفاظ على الاستقرار [6:01] والتوافر العالي الذي [6:02] نطمح إليه ليس عذرًا [6:03] للتباطؤ. هذه هي [6:04] الأمور التي نعتقد [6:06] أننا نحتاجها لنتمكن [6:07] من إطلاق التحديثات [6:08] بهذه الوتيرة مع [6:09] الحفاظ على التوافر [6:10] العالي. لذلك، نحرص [6:11] على أن تكون التغييرات [6:13] صغيرة. فعندما نتحدث [6:14] عن إطلاق 200 عملية نشر، [6:16] قد يكون هناك ثلاثة [6:18] طلبات سحب لكل عملية [6:19] نشر، أي ما يعادل 600 أو [6:21] 700 أو حتى 1000 تغيير. [6:23] لسنا سحريين، فقد [6:24] شهدنا 250 مساهمًا [6:26] فريدًا في Rails خلال [6:27] الشهر الماضي. وهذه [6:29] ليست ميزات كبيرة في [6:31] طلب سحب واحد، بل هي [6:33] طلبات سحب صغيرة جدًا. [6:35] إنها تُنفذ أصغر وأبسط [6:37] مهمة ممكنة في طلب سحب [6:39] واحد. والأمر التالي [6:41] بالغ الأهمية هو جمع [6:43] أدلة موثوقة أثناء [6:44] عملية النشر وبعدها. [6:46] بالنسبة لنا، هذا يعني [6:48] مجموعة اختبارات [6:49] ممتازة ومراجعات [6:50] دقيقة. وبمجرد دخولنا [6:52] مرحلة الإنتاج، نحتاج [6:54] إلى مراقبة دقيقة لما [6:55] يحدث فعليًا أثناء [6:57] عودة الإصدار. وإذا [6:58] كنا ننشر هذا بسرعة، [7:00] فقد تظهر بعض المشاكل [7:01] أحيانًا، لذا نحتاج [7:03] إلى سرعة استعادة [7:04] فائقة. عند النقر على " [7:06] تراجع"، نريد أن يكون [7:08] ذلك فوريًا تقريبًا. [7:09] أما خطوط الإنتاج [7:10] البطيئة فهي عبارة عن [7:12] خيارات متراكمة. كما [7:13] ذكرتُ سابقًا، عندما [7:15] انضممتُ، كنا ننشر [7:16] إصدارات جديدة، وكان [7:17] النقر على "دمج" يستغرق [7:19] حوالي 30 دقيقة. كنتُ [7:20] أعمل في شركة أخرى كنا [7:22] ننشر فيها إصدارًا [7:23] جديدًا كل 6 أسابيع. [7:24] لذا، شعرتُ أن هذه الـ [7:26] 30 دقيقة كانت رائعة [7:27] حقًا. ثم خلال العامين [7:29] الماضيين، كان لدينا [7:30] اتفاقية مستوى خدمة (SLA [7:32] ) P75 للشحن الكامل، [7:33] والتي كانت مدتها 15 [7:35] دقيقة. كان ذلك رائعًا [7:37] بالفعل. لكن مع حجم [7:39] الكود، والتغييرات، [7:43] وطلبات السحب، أدركنا [7:44] أن هذا غير كافٍ. كان [7:46] علينا تحسين أدائنا. [7:47] حتى للحفاظ على [7:48] اتفاقية مستوى الخدمة [7:49] عند 15 دقيقة، كنا نعلم [7:51] أننا بحاجة إلى بذل [7:52] جهد كبير. بدأنا العمل [7:53] بجد ورأينا تحسينات [7:54] متزايدة، حتى أنها [7:55] فاقت توقعاتنا. في [7:56] النهاية، تجاوزنا [7:57] بكثير مستوى اتفاقية [7:58] مستوى الخدمة. هذه هي [8:02] حلقة التعلم الخاصة [8:03] بنا في التكامل [8:04] المستمر/التسليم [8:05] المستمر (CI/CD). المرحلة [8:06] الأولى هي كتابة مهندس [8:07] للكود. لن أتطرق إلى [8:08] هذا الموضوع بالتفصيل [8:09] ، فقد تحدثنا عنه في [8:10] محاضرات أخرى، [8:11] وتناولت وزارة الأمن [8:12] الداخلي الأمريكية [8:13] بعض جوانبه [8:13] المستقبلية. أعتقد أن [8:14] طريقة كتابة الكود قد [8:16] تغيرت بشكل جذري، [8:17] وستستمر في التغير [8:18] بشكل جذري. أعتقد أن [8:20] العناصر المتبقية هنا [8:21] ستتغير أيضًا، ولكن [8:23] ربما ليس بهذه السرعة، [8:24] لأنه بمجرد حدوث تغيير [8:26] ، يجب إدخاله في بيئة [8:27] الإنتاج بأمان أمام [8:29] العملاء. وعلى الأقل [8:30] في الوقت الحالي، ربما [8:32] ستة أشهر، أو سنة، أو [8:34] سنتين، يبدو الأمر [8:35] كالتالي. لذا، عند [8:36] حدوث التغيير، نقوم [8:39] بمراجعة، ثم نقوم [8:41] بالتوازي بتشغيل [8:42] مجموعة الاختبارات، [8:43] ثم نبني أداة قابلة [8:45] للنشر. نجري بعض [8:46] الاختبارات الأولية، [8:47] ثم ننشرها في بيئة [8:48] الإنتاج. سألقي نظرة [8:50] أولًا على مجموعة [8:51] الاختبارات لدينا [8:52] وكيفية تشغيلها. هذا [8:54] هو عدد الاختبارات من [8:56] عام 2012 إلى عام 2016 في [8:58] نظامنا المتكامل. [9:00] عندما انضممت، أعتقد [9:01] أن إيراداتنا السنوية [9:02] المتكررة كانت حوالي 60 [9:03] أو 70 مليونًا. هذه [9:05] بيانات عام 2016. عندما [9:07] تحققت، كان لدينا [9:08] حوالي 16000 اختبار. لقد [9:10] ضاعفنا مجموعة [9:11] الاختبارات لدينا في [9:12] العام الماضي. وفي [9:14] أغسطس، أضفنا 25000 [9:16] اختبار. نعم. إذن، هذه [9:19] إحدى مشاكلنا. كما [9:21] لاحظتم، يمكن للوكلاء [9:23] الانغماس في التفاصيل [9:25] ، وكتابة الاختبارات [9:26] شيء، وكتابة [9:27] التعليقات شيء آخر. [9:29] رأينا في Opus 48 أن عدد [9:31] التعليقات التي تم [9:32] إنشاؤها تضاعف ثلاث [9:34] مرات تقريبًا. لقد [9:36] تمكنا من السيطرة على [9:37] الوضع نوعًا ما. نعم، [9:40] كان من الصعب جدًا جعل [9:42] Cloud يقوم بما نريده. [9:44] لكن لا تزال هناك [9:45] مشاكل. هذا يعني 225,000 [9:48] مواصفة. وإذا كنت تعمل [9:50] بشكل متسلسل، فهذا [9:51] يستغرق حوالي 60 ساعة. [9:53] طلب السحب النموذجي لا [9:55] يغير سوى أربعة ملفات. [9:58] هل يمكننا فعل ما هو [9:59] أفضل من ذلك؟ الإجابة [10:01] المختصرة هي نعم. [10:03] نستخدم Rotoscope، وهي [10:05] أداة من Shopify. إنها [10:07] مسجل عالي الأداء [10:09] لمؤشرات الأساليب. [10:10] صحيح أنها ليست مصممة [10:12] لاختيار الاختبارات، [10:13] لكننا كنا فعالين [10:14] للغاية في استخدامها [10:16] لمساعدتنا في بناء [10:17] نظام لاختيار [10:18] الاختبارات. باختصار، [10:20] نستخدم جهاز Rotoscope كل [10:22] 5:00 صباحًا. لدينا جميع [10:25] مواصفاتنا، ونُشغّلها [10:26] جميعًا عبر Rotoscope، مما [10:28] يُنشئ ملفًا باسم " [10:30] ملفات التغييرات". [10:31] نقوم بذلك مرة واحدة [10:33] يوميًا لأنه يستغرق [10:34] وقتًا طويلًا. بعد ذلك [10:36] ، نُجري تعديلًا عليه [10:38] كل 30 دقيقة. يبدو الملف [10:44] كالتالي: كما ترون على [10:45] الجانب الأيسر، لدينا [10:47] المواصفات A و B و C و D. [10:48] عند تشغيل المواصفات A [10:50] و B و C، يتم تحديث ملف [10:52] conversation.rb. وعند تشغيل [10:53] المواصفات D، يتم [10:55] تحديث ملف billing.rb. هذا [10:58] يُتيح لنا إنشاء ملف [11:02] البحث هذا. كما ترون، [11:04] يرتبط ملف conversation.rb [11:06] بالمواصفات A و B و C. [11:10] هذا يعني أنه إذا كان [11:11] لديك طلب سحب وقمت [11:13] بتغيير ملف conversation.rb، [11:14] فسيتم تشغيل [11:15] المواصفات A و B و C فقط، [11:17] ولن يتم النظر في [11:19] المواصفة D إطلاقًا. قد [11:20] يبدو الأمر محفوفًا [11:22] بالمخاطر، ولكن هذا هو [11:24] السبب في أنه ليس كذلك. [11:25] لدينا مجموعة من [11:30] المواصفات الأساسية [11:31] التي يتم تشغيلها [11:32] دائمًا، والتي قد تكون [11:34] خاصة ببعض عمليات سير [11:35] العمل الأساسية [11:36] للمنتج وبعضها الآخر [11:37] متعلق بالأمان. هناك [11:38] أيضًا أدلة مختلفة، [11:39] فإذا طرأ تغيير عليها، [11:41] فلن نخمن، بل سنقوم [11:42] بتشغيل مجموعة [11:43] الاختبارات الكاملة. [11:45] وكما ذكرت، نقوم [11:46] بتحديث البيانات كل 30 [11:48] دقيقة، فإذا أنشأت طلب [11:49] سحب بناءً على آخر [11:51] تحديث قبل 30 دقيقة، [11:52] فقد تكون هناك [11:53] اختبارات جديدة لم يتم [11:55] اختبارها. لذلك، نقوم [11:56] باختبار أي شيء حتى [11:58] التحديث التالي. ثم [11:59] نُضيف خانة تخطي حيث [12:00] يمكنك إضافة التزام [12:02] فارغ، وسيقوم النظام [12:03] أيضًا بتشغيل كامل. [12:04] وفي بعض الأحيان، قد [12:06] تواجه ما نسميه حوادث [12:08] النشر. على سبيل [12:09] المثال، إذا كان هناك [12:10] ثلاثة أو أربعة أشخاص [12:12] يعملون على طلب سحب، [12:13] وقد اجتازوا جميعًا [12:14] اختبار Rotoscope بنجاح، [12:15] ولكن قبل وصولهم إلى [12:17] بيئة الإنتاج، سنجري [12:18] اختبارًا كاملًا آخر، [12:19] وقد يعني Rotoscope أنك [12:20] ستوقف خط الأنابيب. أو [12:22] قد يكون هناك مشكلة في [12:23] قائمة الدمج، لكننا [12:24] قمنا ببناء أدوات [12:25] تُمكّنك من معرفة ما [12:26] عليك فعله بالضبط [12:27] لإصلاح الموقف في غضون [12:28] 30 ثانية. إذن، ما هي [12:30] النتائج؟ لقد قللنا [12:32] وقت مجموعة الاختبار [12:33] من أكثر من 7 دقائق [12:34] ونصف إلى أقل من 3 [12:36] دقائق. في الواقع، لقد [12:37] قللنا وقت مجموعة [12:38] الاختبار الكاملة إلى [12:40] أقل من 3 دقائق أيضًا. [12:41] لقد تركنا 3 دقائق كوقت [12:44] محدد لهذه المرحلة. [12:49] لكن الميزة الكبرى [12:51] تكمن في أن مجموعة [12:52] الاختبارات المختارة [12:54] تستهلك حوالي 5%فقط من [12:56] موارد الحوسبة [12:57] اللازمة لتشغيلها. ومع [13:00] ازدياد طلبات السحب، [13:01] ارتفع عدد عمليات [13:03] التكامل المستمر (CI) [13:04] التي نقوم بها ثمانية [13:06] أضعاف خلال تلك الفترة [13:08] . لذا، ارتفعت [13:09] تكاليفنا بشكل كبير [13:11] خلال السنوات الست أو [13:12] السبع الماضية، حيث [13:14] اعتدنا على النمو [13:15] الأسي. لو لم نبدأ [13:16] العمل على هذا الأمر [13:18] العام الماضي، لكانت [13:19] فاتورة التكامل [13:20] المستمر (CI) تعادل [13:21] الناتج المحلي [13:22] الإجمالي لدولة صغيرة. [13:23] كانت تتزايد باستمرار. [13:25] لذلك، قال المدير [13:26] المالي: "لا يمكنكم [13:28] الاستمرار على هذا [13:29] المنوال". كان هذا أحد [13:30] العوامل المحفزة لبعض [13:32] هذا العمل. لقد أحبوا [13:33] هذا التغيير، وأحب [13:34] المهندسون التحسينات [13:36] في سرعة الإنجاز التي [13:37] حققها. ولكن هناك [13:39] المزيد أيضًا. فعند [13:40] تشغيل عرض أصغر [13:41] لمجموعة الاختبارات، [13:42] يقل عدد الأخطاء بشكل [13:44] ملحوظ. إذن، يُعتبر [13:45] الاختبار غير المستقر [13:46] بمثابة مشكلة من [13:47] الدرجة الأولى (P1) خلال [13:48] النهار بالنسبة لنا. [13:49] بمعنى آخر، يُنشئ هذا [13:50] الاختبار مشكلة من [13:51] الدرجة الأولى (P1). يجب [13:52] على مهندس الدعم [13:53] المناوب إصلاح هذا [13:54] الخلل بأسرع ما يمكن. [13:55] ولدينا أيضًا وكلاء [13:56] يقومون بذلك في [13:57] الخلفية. مع ذلك، من [13:59] الأفضل تجنب حدوث [14:00] اختبار غير مستقر على [14:02] الإطلاق. حسنًا، بمجرد [14:04] تحديد الاختبارات، [14:06] كيف يتم تشغيل الملفات [14:08] ؟ نحن لا نجمع الملفات [14:10] حسب نوعها، بل حسب [14:12] مدتها. في كل مرة نشغل [14:14] فيها اختبارًا، نسجل [14:16] الوقت المستغرق. ثم، [14:18] في كل مرة نستعد فيها [14:20] لتشغيل الاختبار، [14:21] نحاول توزيع وقت [14:23] التشغيل بحيث يكون لكل [14:24] مجموعة نفس المدة [14:26] تقريبًا. عند إجراء [14:28] اختبار كامل، لدينا [14:30] حوالي 1400 عامل يقومون [14:32] بذلك بالتوازي. عند [14:34] إجراء اختبار مثل [14:36] اختبار الروتوسكوب، [14:37] لا نستخدم كل تلك [14:38] الحاويات البالغ [14:39] عددها 1400. بل نستخدم [14:41] العدد اللازم فقط [14:42] للحفاظ على مدة [14:43] الاختبار حوالي 3 [14:44] دقائق. هكذا نختار [14:47] الاختبارات ونشغلها. [14:49] أما بالنسبة لـ boot، [14:51] فهو تكلفة تُدفع في كل [14:53] مرة، سواءً عند تشغيل [14:55] مجموعة اختبارات أو [14:57] حتى عند النشر. وهناك [14:59] بعض الأمور التي [15:00] وجدناها مؤثرة جدًا في [15:02] تحسين الأداء. لذا، هل [15:04] من أحد لديه تطبيق [15:06] إنتاجي قبل Rails 5.2؟ [15:11] حسنًا، قليلون فقط. [15:13] إذًا، أصبح boot snap [15:17] جوهرة افتراضية منذ [15:19] Rails 5.2. وظيفته [15:21] الافتراضية هي ملء [15:23] ذاكرة التخزين المؤقت [15:24] للتعليمات البرمجية [15:25] المترجمة بشكل كسول، [15:27] وهذا ممتاز بالفعل. [15:28] لذا، عند بدء التشغيل [15:30] لأول مرة، ستواجه بعض [15:32] التأخير، ولكن لاحقًا [15:34] ستتمكن عمليات أخرى من [15:35] استخدام هذه الذاكرة [15:37] المؤقتة. كما نقوم [15:38] أيضًا بتجميعها [15:39] مسبقًا عند إنشاء [15:40] الصورة. فعند إنشاء [15:41] الصورة، نقوم بذلك [15:43] بالفعل. لذا، في كل مرة [15:46] يبدأ فيها مُشغّل يرغب [15:47] في تشغيل مجموعة [15:48] الاختبارات، يكون [15:49] لديه ذاكرة مؤقتة [15:51] جاهزة، مما يُسرّع [15:52] عملية الانتقال من طلب [15:53] بدء تشغيل الاختبار [15:55] إلى تشغيل الاختبارات [15:56] فعليًا. أما بالنسبة [16:02] لذاكرة التخزين [16:03] المؤقت للمخطط، فلم [16:05] يكن هذا تحسينًا [16:06] للأداء قمنا به مؤخرًا [16:07] ، بل كنا نقوم به منذ [16:09] سنوات، حتى قبل [16:10] انضمامي. فعندما تبدأ [16:13] عملية Rails، من أول [16:14] الأشياء التي تقوم بها [16:17] هو عرض جميع الحقول في [16:19] كل مرة تصل فيها إلى [16:21] جدول، وذلك لفهم بنية [16:24] جدول قاعدة البيانات. [16:26] وهذا جيد عندما يكون [16:27] النظام صغيرًا، ولكن [16:29] بمجرد أن يبدأ بالتوسع [16:30] ويصبح لديك عشرات أو [16:32] حتى مئات العمليات [16:33] التي تُعاد تشغيلها [16:35] بعد بدء التشغيل، فقد [16:36] يتسبب ذلك في انقطاعات [16:38] . قبل حوالي 10 أو 11 [16:39] عامًا، كان هذا يُسبب [16:40] انقطاعًا بسيطًا في كل [16:42] مرة ننشر فيها على [16:43] بيئة الإنتاج لأن كل [16:44] هذه العمليات كانت [16:46] تُرهق قاعدة البيانات. [16:47] لذا، يُمكنك استخدام [16:49] Rails لإنشاء نسخة [16:50] احتياطية من مخطط [16:51] قاعدة البيانات. نقوم [16:53] بذلك عن طريق حفظها في [16:55] ملف S3، ثم في كل مرة [16:57] تبدأ فيها عملية، يتم [16:59] الرجوع إلى ملف S3 [17:01] والحصول على أحدث مخطط [17:03] . وبالتالي، لا يحتاج [17:04] النظام إلى إجراء [17:05] استدعاءات لعرض [17:06] الحقول كاملة. الآن، [17:09] هذه النقطة مثيرة [17:10] للاهتمام. يتعلق الأمر [17:12] بتحليل أداء التكامل [17:14] المستمر (CI). إنه أشبه [17:15] بالغوص في التفاصيل [17:17] الدقيقة وفهم ما يحدث. [17:18] وكما أن بعض هذه [17:20] المهام قد أنجزها [17:21] البشر، فإن العملاء [17:22] بارعون فيها أيضاً. [17:23] يمكنك إرسالهم في [17:25] مهمات لمحاولة حل [17:26] المشكلة حتى بدون بذل [17:28] جهد هندسي كبير. يقوم [17:29] هذا الكود، أو بالأحرى [17:31] هذه الطريقة، بتحديد [17:33] موقع المصدر لكل [17:35] استعلام SQL. وهذا مفيد [17:37] جداً في حال وجود [17:38] مشكلة في قاعدة [17:40] البيانات، حيث سيظهر [17:42] لك سطر من كود Ruby يُسبب [17:45] هذا الاستدعاء. يبدو [17:47] الكود على اليسار [17:48] جيداً، فقد كنا نشغله [17:50] لسنوات طويلة، لكن [17:51] المشكلة كانت أنه [17:52] يُنشئ سلسلة [17:53] استدعاءات كاملة [17:54] باستخدام المُستدعي، [17:55] ثم يمر على كل سطر [17:56] ويُنشئ كائناً في كل [17:58] مرة. لذا، فإن سلسلة [17:59] الاستدعاءات لدينا [18:00] قديمة جداً، وقد يصل [18:01] عمقها إلى مئات الصفوف [18:02] . وبالتالي، على الرغم [18:04] من أنها ليست بطيئة [18:05] ظاهرياً، إلا أنها [18:06] تصبح بطيئة عند [18:07] تكرارها كثيراً. إذن، [18:09] كان الإصدار الموجود [18:10] على اليمين أشبه [18:11] بعملية اجتياز كسولة [18:13] مع فحص لا يتطلب [18:14] تخصيصًا. ونتيجة لذلك، [18:15] أصبح أسرع بعشر مرات، [18:17] مما وفر لنا حوالي 20%من [18:18] وقت تشغيل التكامل [18:20] المستمر (CI) بفضل هذا [18:21] التغيير البسيط. وكما [18:23] أفاد التكامل المستمر [18:24] ، فقد أفاد بيئة [18:25] الإنتاج أيضًا. الخطوة [18:28] التالية هي التوقف عن [18:29] العمل عندما لا تتغير [18:31] المدخلات. هناك العديد [18:32] من الإجراءات التي [18:33] نقوم بها بشكل افتراضي [18:34] ، حيث نبدأ من جديد في [18:36] كل مرة، وهذا غير [18:37] ضروري. على سبيل [18:37] المثال، نعيد استخدام [18:39] ذاكرة التخزين المؤقت [18:40] لمخطط ما بعد الترحيل [18:41] حتى يتم تغيير ملف [18:42] schema.rb أو db/migrate. لذا، [18:43] لا داعي لإعادة هذه [18:44] العملية. وينطبق الأمر [18:46] نفسه على تثبيت الحزم. [18:47] فما لم يتغير ملف Gemfile [18:49] أو ملف القفل، فلا [18:50] داعي لإعادة العملية. [18:52] وهذه مجرد أشياء صغيرة [18:54] تستغرق 5 ثوانٍ هنا، و [18:55] 10 ثوانٍ هناك، ويمكنك [18:57] تحسين هذا الأداء [18:58] باستمرار. لذا، نعم، [19:00] ملف تعريف التمهيد. [19:02] نعم، توقف عن القيام [19:03] بالعمل الثابت وحسّن [19:05] العمل عالي التردد. [19:06] الآن، سأتحدث عن مرحلة [19:08] البناء. عندما كنا [19:11] نبني الأصول القابلة [19:12] للنشر، والتي نسميها " [19:14] الوحدات البرمجية"، [19:15] كنا نبني ستة. وكان هذا [19:17] في الغالب ديونًا [19:18] تقنية كنا نحملها، [19:19] وحتى أصبح لدينا هذا [19:20] النوع من القوة [19:21] والوظيفة من حيث كمية [19:23] الفواتير أو عدد طلبات [19:24] السحب التي تمر، وعدد [19:26] عمليات التكامل [19:27] المستمر، وعدد عمليات [19:28] النشر، تجاهلناها [19:30] نوعًا ما. ولكن، كنا [19:31] نبني ستة، وكان ما كنا [19:33] نفعله هو أننا كنا [19:35] نبني لبنيتين وثلاث [19:36] مناطق. ثم البنيتين، [19:38] كنا نبني للحصول على [19:40] الكثير على x86. وكانت [19:41] بنية x86 مخصصة لميزة [19:43] واحدة فقط. كان ذلك [19:44] لمشروع إنشاء ملفات PDF [19:45] كنا نعمل عليه. ولم نكن [19:47] نكترث به كثيرًا. ولكن [19:49] في مرحلة ما، قلنا: " [19:50] حسنًا". كان لديّ مهندس [19:52] جديد ينضم إلى أحد [19:53] فرقنا. قلت له: "هذا [19:54] مشروع رائع لتبدأ به [19:56] وتتعرف على أسلوب [19:57] عملنا هنا". وهكذا، [19:58] ألغى ذلك المشروع. [20:00] تمكّنا من إيجاد طريقة [20:01] أخرى لإنشاء ملفات PDF. [20:03] هذا قلّص عدد الخوادم [20:04] إلى ثلاثة. ولدينا [20:05] ثلاث مناطق ننشر فيها. [20:07] ولم يكن هناك سبب وجيه. [20:08] أنجزنا العمل ببساطة. [20:10] واختصرنا العدد إلى [20:11] خادم واحد. تكمن أهمية [20:13] هذا في أننا كنا نشغله [20:14] بالتوازي، ولكن كانت [20:16] تحدث أعطال بين الحين [20:18] والآخر. وإذا كررت نفس [20:20] العملية ست مرات، [20:21] فستكون الأعطال أكثر [20:23] من تكرارها مرة واحدة. [20:24] لذا، قلّل هذا من عدد [20:26] الأعطال، وبالتالي [20:27] قلّل من الموارد التي [20:28] نحتاجها. الخطوة [20:30] التالية هي التخلص من [20:31] عبء زائد. لذا، انظر [20:33] جيدًا إلى ما تقوم [20:34] بنشره. كنا ننقل وحدات [20:37] Spec Node ووحدات bin Node إلى [20:39] كل نسخة تشغل التطبيق. [20:42] كنا ننشر مواصفاتنا [20:44] لسنوات طويلة، في كل [20:46] مرة. حسبت ذلك سابقًا، [20:50] ووجدت أننا كنا نضغط [20:52] الملفات وننشرها 500,000 [20:55] مرة يوميًا، ثم نفك [20:57] ضغطها. لذا، انظر [21:00] جيدًا إلى ما تنشره، [21:02] وإذا لم يكن ضروريًا، [21:04] فاحذفه. هذه النقطة [21:06] مثيرة للاهتمام. انظر [21:08] إلى التغييرات التي [21:10] تحدث عند ترقية Gems أو [21:11] ما شابه. هذا التحديث [21:13] في Tailwind CSS يعطل ذاكرة [21:15] التخزين المؤقت [21:16] للأصول في بيئة [21:17] الإنتاج. كان تغييرًا [21:19] منطقيًا. ظلّت المشكلة [21:21] قائمةً لخمس سنوات قبل [21:23] أن نلاحظها، وكان [21:24] شعارنا "نُنشئ أصلًا [21:25] قابلًا للنشر"، وقد [21:27] تسبّب هذا التغيير في [21:28] تباطؤ العملية [21:29] دقيقتين طوال تلك [21:30] السنوات الخمس. تخيّل [21:32] فقط كمية دورات [21:33] الحوسبة التي [21:34] استهلكناها في هذا [21:35] الأمر. حسنًا، وهذه [21:37] بعض النتائج. أنا، جان [21:39] ، مهندس Ruby الأساسي، [21:41] كنتُ مسؤولًا عن بناء [21:43] البرنامج، وقد أقنعنا [21:45] به وأراد تطويره. [21:46] وهكذا، انخفض وقت [21:47] التنفيذ من أربع دقائق [21:49] ونصف إلى 53 ثانية. لم [21:51] يكن هناك سرٌّ حقيقيٌّ [21:52] في الأمر، بل كان [21:54] الأمر ببساطة عبارة عن [21:55] مراقبة أداء النظام، [21:56] وتحليل العمليات، [21:57] وإضافة إمكانية [21:58] المراقبة، ثمّ تحسين [22:00] الأداء. نعم، تحليل [22:01] عمليات البناء، [22:02] وتحليل عمليات [22:03] التشغيل والبناء. أي [22:05] التوقف عن القيام [22:06] بالعمليات الثابتة، [22:07] وتحسين العمليات [22:08] عالية التردد، وتخزين [22:09] البيانات مؤقتًا حتى [22:10] تتغير. حسنًا، سأنتقل [22:11] الآن إلى الخطوة [22:12] التالية: بمجرد [22:13] الانتهاء من بناء [22:14] التطبيق، نقوم، [22:15] بالتوازي مع مجموعة [22:16] الاختبارات، بتشغيل [22:18] عدد من اختبارات [22:19] التحقق السريع. نتحقق [22:20] من الاتصالات بالبنية [22:22] التحتية الحيوية [22:23] الحقيقية، ثم نقوم [22:25] بمهام أمنية أخرى [22:26] متنوعة. بعد ذلك، [22:29] نحتاج إلى نشره على [22:31] جميع الخوادم. لدينا [22:33] آلاف خوادم EC2 لتشغيل [22:34] نظامنا المتكامل. ما [22:36] نفعله هو أننا نحمل [22:38] الملف إلى S3، ثم [22:39] نستخدم SSM لإرسال طلب [22:41] ping إلى جميع الخوادم [22:43] ونخبرهم بوجود إصدار [22:45] جديد. حمّلوه وابدأوا [22:47] بتدوير العمليات. [22:48] يستغرق تدوير [22:49] العمليات حوالي 3 أو 4 [22:50] دقائق، ونحتفظ أيضًا [22:52] بالإصدارات الأربعة [22:53] السابقة من التطبيق [22:54] على كل خادم، وستعرفون [22:56] السبب بعد قليل. هذا هو [22:59] النظام الداخلي الذي [23:00] يدير كل هذا، والذي [23:02] أطلقنا عليه اسم Muster. [23:04] دارا، مدير قسم [23:05] التكنولوجيا لدينا، [23:07] هو من بدأ العمل على [23:08] هذا المشروع قبل 15 [23:10] عامًا، وأعلم أن واجهة [23:12] المستخدم هذه لن تُعجب [23:13] إلا الآباء. لدينا [23:16] مصمم سينضم إلينا [23:18] للعمل عليها، وسيكون [23:19] التركيز على تجربة [23:21] المستخدم. واجهنا على [23:23] مر السنين بعض المشاكل [23:25] حيث ارتكب المستخدمون [23:27] أخطاءً بسبب عدم [23:28] وضوحها. لذا، سنعمل [23:29] على تحسينها وجعلها [23:31] أكثر جاذبية، فهي [23:32] تحتوي على الكثير من [23:34] المعلومات المفيدة. من [23:37] بين الأمور التي نحرص [23:38] عليها هو إبقاء مقاييس [23:40] الأداء في صميم عملنا. [23:41] هذا يُعزز المساءلة [23:42] لفريقنا ويُظهر [23:44] للمهندسين، فقد [23:45] تلقيتُ مؤخرًا [23:46] تعليقًا من أحد [23:47] المهندسين يقول فيه: " [23:48] يا رجل، نحن نُصدر [23:49] التحديثات بسرعة [23:50] كبيرة جدًا. لا أستطيع [23:52] حتى تحضير القهوة عند [23:53] النقر على زر الدمج." [23:55] لذا، نريد إبقاء [23:57] المهندسين على اطلاع [23:59] دائم بمدى سرعة وصول [24:00] المنتج إلى مرحلة [24:01] الإنتاج. وأنا جادٌّ [24:03] تمامًا في عملي. لدينا [24:05] نافذة زمنية مدتها 11 [24:07] دقيقة، ونقوم بالنشر [24:08] خمس مرات. لذا، نحن [24:10] نعمل جاهدين على نشر [24:11] المنتج بأسرع ما يمكن. [24:16] فالإنتاج ليس هو [24:17] الغاية، بل ما يفعله [24:19] عملاؤنا به، وهذا يؤثر [24:21] على التغييرات [24:22] اللاحقة. سأستعرض الآن [24:25] بعض الدروس السلبية [24:27] المستفادة وكيفية [24:28] تعديلها. لدينا مفهوم [24:32] يُسمى "مؤشرات نبض [24:34] القلب"، حيث نحاول [24:35] مراقبة النتائج، وليس [24:38] الأنظمة فقط. مهمتنا [24:40] في Finn هي تمكين [24:42] عملائنا من إجراء [24:43] حوارات مثمرة مع [24:45] عملائهم، ولدينا [24:46] مؤشرات تساعدنا على [24:48] فهم ذلك. فماذا يحدث [24:50] عندما يتحدث عملاؤنا [24:52] مع عملائهم؟ هذا ما [24:53] يحدث بالفعل، مثل [24:54] تبادل التعليقات. [24:56] يتنقل زملاؤنا في [24:57] الفريق بين صناديق [24:58] البريد الوارد، بينما [24:59] يقوم فريق الدعم الفني [25:00] بحل المحادثات. لدينا [25:01] مقاييس عالية الحجم [25:03] لهذا الأمر، وبمجرد [25:04] حدوث أي انحراف، نعلم [25:06] أن هناك مشكلة. في هذه [25:08] الحالة تحديدًا، [25:09] بتاريخ 25 أغسطس، قام [25:11] أحد المهندسين بنشر [25:13] استعلام خاطئ. وكما [25:15] ترون هنا، وصل هذا [25:16] الخطأ إلى بيئة [25:18] الإنتاج. في الأسفل، [25:20] يتم إطلاق إنذار. [25:22] حاليًا، ننتظر [25:23] دقيقتين قبل إطلاق [25:25] الإنذار. كنا قد [25:26] ضبطناه على 30 ثانية، [25:27] لكن ذلك كان يتسبب في [25:28] الكثير من الإنذارات [25:29] الكاذبة. نعمل [25:30] باستمرار على تقليل [25:31] هذه المدة قدر الإمكان [25:32] . حاليًا، هي دقيقتان، [25:34] ولكن ربما إذا تحدثت [25:35] معي خلال أسبوعين، قد [25:36] تصبح دقيقة واحدة. يتم [25:37] إطلاق الإنذار، ويقوم [25:38] بإنشاء بلاغ فوري، [25:40] واستدعاء قائد [25:41] الحوادث، واستدعاء [25:42] فريق الهندسة، وإعادة [25:43] النظام إلى وضعه [25:44] السابق في بيئة [25:45] الإنتاج. كما ذكرتُ [25:47] سابقًا، جميع [25:48] تغييراتنا طفيفة جدًا. [25:50] لذا، حرصنا على أن [25:51] يكون التراجع عن [25:52] الإنتاج آمنًا دائمًا. [25:53] لن نتراجع إلى إصدار [25:54] سابق لمدة ساعتين أو [25:55] أربع ساعات، لأن واجهة [25:57] المستخدم قد تكون قد [25:58] تقدمت بالفعل. لكننا [25:59] نتراجع إلى إصدار سابق [26:01] يصل إلى خمس نسخ، أي [26:02] إلى ما قبل 20 دقيقة. [26:04] هنا، كما ترون، يبدأ [26:06] التراجع التلقائي. [26:08] وهنا، نرى عملية [26:09] استعادة كاملة. هذا [26:11] حادث لم يتدخل فيه أي [26:12] عنصر بشري في عملية [26:13] الاستعادة. كان كل شيء [26:15] حتميًا، ولم يكن له [26:16] علاقة ببرامج إدارة [26:16] دورة حياة المنتج. كان [26:18] الأمر برمته حتميًا، [26:19] محاولةً لإصلاح الوضع. [26:21] استغرق هذا الحادث من 6 [26:22] إلى 7 دقائق. قبل سنوات [26:24] ، لنقل قبل 4-5 سنوات، [26:25] كان هذا النوع من [26:26] الحوادث يستغرق حوالي [26:27] 11-12 دقيقة، حيث كان [26:28] ينطلق إنذار في مكان [26:29] ما، ثم يصل المهندسون، [26:31] ويحاول أحدهم إصلاح [26:32] المشكلة، ثم يتذكرون: " [26:33] حسنًا، يمكننا [26:34] التراجع. سنقوم [26:36] بالتراجع." والتراجع [26:38] بطيء نوعًا ما، [26:39] ويستغرق 15 دقيقة. أما [26:40] هنا، فيستغرق 6-7 دقائق. [26:42] في الوقت الحالي، لو [26:43] كان لدينا نفس الشيء، [26:44] لكان حوالي 4 دقائق. [26:45] لكننا نعمل على تقليل [26:47] ذلك أكثر. هذا هو [26:50] التراجع. بالطبع، [26:51] نستخدم ميزات الأمان، [26:53] فإذا كنت مهندسًا، [26:54] تقوم بالنشر باستخدام [26:56] ميزة الأمان أولًا، [26:57] ولكن هناك بعض [26:58] التغييرات حيث تحتاج [27:00] فعليًا إلى إجراء نشر [27:01] قياسي. أنا مسؤول عن [27:05] بعض ضوابط الامتثال [27:07] لدينا، وكنت أتحدث مع [27:09] مدقق حسابات. سألني [27:12] سؤالاً حيرني قليلاً: " [27:14] اشرح لي مستويات النشر [27:16] منخفضة ومتوسطة [27:18] وعالية المخاطر لديكم" [27:20] . شاهدتُ العديد من [27:22] البرامج التلفزيونية [27:23] القانونية، حيث [27:24] يحاولون تجهيز الشاهد [27:26] ، ويقولون: "أجب فقط [27:27] على ما يُطلب منك [27:28] فعلاً". كان هذا يدور [27:29] في ذهني طوال الوقت: " [27:31] لا تقل أي شيء سخيف". ثم [27:33] أدركتُ أننا في الواقع [27:34] لا نستخدم مستويات نشر [27:36] منخفضة ومتوسطة [27:38] وعالية المخاطر. نحن [27:40] نتعامل مع جميع [27:41] التغييرات على أنها [27:42] عالية المخاطر حتى [27:43] يثبت العكس. ونقوم [27:45] بذلك من خلال البدء في [27:46] كل تغيير من خط الأساس [27:48] لهذه الضوابط [27:49] الأساسية. إذن، ينطبق [27:51] هذا على كل تغيير، [27:52] سواء كان تغييرًا لنص [27:54] زر ما في صفحة [27:55] الإعدادات، أو إعادة [27:57] توجيه التطبيق إلى [27:58] قاعدة بيانات جديدة. [28:01] فالأمر سيان. لدينا [28:02] مراجعة وموافقة [28:04] دقيقتان، واختبارات [28:05] آلية ممتازة، [28:06] واختبارات أولية [28:08] سريعة، ونشر تدريجي [28:10] سريع، وإمكانية [28:11] التراجع التلقائي عند [28:13] حدوث أي مشكلة. هذا [28:14] ينطبق على كل تغيير، [28:16] بغض النظر عن المخاطر [28:18] أو المُنشئ أو [28:19] المُعتمد. لماذا أتحدث [28:22] عن هذا؟ لأن تكلفة [28:24] إنشاء الكود أصبحت [28:26] منخفضة للغاية، وأصبح [28:28] أكثر من 95%من طلبات [28:30] السحب تتم آليًا منذ [28:32] ستة أشهر تقريبًا. [28:34] وتشير الأرقام إلى [28:34] زيادة سرعة طلبات [28:35] السحب بمقدار ثلاثة [28:36] أضعاف خلال 16 شهرًا، [28:37] بل وصلت إلى أربعة [28:38] أضعاف الأسبوع الماضي. [28:40] لذا، تسير الأمور [28:41] بوتيرة أسرع بكثير. [28:43] وهذا يقودنا إلى [28:44] مراجعة الكود. إذن، [28:46] أصبحت المراجعة هي [28:48] العائق، ومثلكم [28:49] جميعًا على الأرجح، [28:51] هذا يعود إلى عامين [28:52] مضت. كان لدينا نظام [28:54] مساعد للمراجعة، ويا [28:56] إلهي، أصبحت [28:57] المراجعات معقدة [28:58] للغاية. كنا نفعّل هذه [29:00] الميزة، وكما كان [29:01] الحال مع كلود عندما [29:02] طلبنا منه إجراء [29:04] المراجعات، كان [29:05] النظام يستقبل طلب [29:06] السحب على GitHub، ثم [29:07] يقوم بالمراجعة، [29:09] ليظهر تعليق طويل جدًا [29:10] أشبه برسالة حب لرمزك. [29:12] تقول لنفسك: "أحب هذا [29:14] التجريد. فهمت ما [29:15] فعلته. إنه رائع حقًا." [29:18] قد تظهر بعض المشاكل [29:20] في النهاية، ويسرد [29:21] النظام 12 نقطة. معظمها [29:23] غير مفيد. ربما توجد [29:25] بعض الميزات القيّمة، [29:27] لكننا لن نقرأ 2000 كلمة [29:29] في مراجعة طلب سحب. [29:30] لذلك، كان المهندسون [29:32] يتجاهلون هذا التعليق [29:34] وينتقلون إلى مراجعة [29:36] المراجعات البشرية. [29:37] كان الأمر سيئًا [29:39] للغاية. وما أردنا [29:42] فعله هو رفع مستوى [29:44] جودة المراجعات، وليس [29:46] مجرد تسريعها. لأننا [29:49] ندرك أنه مع ازدياد [29:51] سرعة معالجة طلبات [29:52] السحب، يزداد الضغط [29:54] على المهندسين للنقر [29:56] على "يبدو جيدًا" [29:57] والسماح للأمر [29:58] بالمرور. لذا، أردنا [30:00] أن تكون المراجعة [30:02] الأساسية ممتازة. لذلك [30:04] ، أنشأنا نظامًا نسميه [30:07] "تريك". وهو بمثابة [30:09] وكيل المراجعة لدينا. [30:11] نحن شركة ذكاء اصطناعي [30:13] ، ولدينا حوالي 100 شخص [30:15] في فريق الذكاء [30:16] الاصطناعي، بالإضافة [30:18] إلى مئات آخرين يعملون [30:20] مع الفريق على [30:21] منتجاتنا. وكما هو [30:23] الحال مع العديد من [30:24] التقنيات التي [30:25] نستخدمها في تطوير [30:26] منتجاتنا التي نبيعها [30:27] لعملائنا، فقد طبقنا [30:29] هذه التقنيات على [30:30] طريقة إجراء [30:31] المراجعات. لدينا كاتب [30:34] ، وطلب سحب، ثم خمس [30:36] مراحل. حسنًا، أغلب [30:40] الكود الذي نكتبه يكون [30:42] باستخدام كود كلود. [30:43] نستخدم أيضًا كود أكتس [30:45] ، لكن أغلب الكود يكون [30:47] باستخدام كود كلود. [30:48] لذلك نستخدم كود أكتس [30:50] في الكثير من هذه [30:51] المرحلة. وهذه خمس [30:53] مراحل مستقلة، يمكننا [30:55] كتابة تقييمات لكل [30:56] منها. المرحلة الأولى [30:58] هي بيان المشكلة. في [31:00] وصف طلب السحب، هل [31:04] توجد مشكلة مفهومة يجب [31:06] حلها؟ ما هو الهدف؟ ما [31:09] هي الفرضية وراء طلب [31:10] السحب هذا؟ لأنه إذا [31:12] لم يكن ذلك موجودًا في [31:14] الوصف، فكيف سيتمكن [31:15] المهندس، سواء كان [31:16] إنسانًا أو برنامجًا، [31:18] من فهم ما إذا كان [31:19] الكود يؤدي ما هو [31:20] متوقع منه؟ لذا، نعم، [31:22] نكتب بيان المشكلة [31:23] ويتم تقييمه. المرحلة [31:25] التالية هي الهدف. لا [31:27] أعرف إن كنتم قد طلبتم [31:28] من كلود القيام بـ "هل [31:29] يمكنك القيام بـ أ؟" ثم [31:31] يقوم كلود بتنفيذ [31:33] الخطوات أ، ب، ج، د. ثم [31:35] يقوم بمجموعة من [31:36] المهام الأخرى. هذه هي [31:38] عملية التحقق لدينا [31:39] للتأكد من أن الكود [31:40] يقوم بما يلي: "حسنًا، [31:41] المشكلة تنص على أن [31:43] الكود يقوم بهذا [31:44] بالفعل؟ هل يقوم [31:45] بأشياء أخرى؟" نعم، [31:47] سأمنحه درجة هنا. [31:49] الخطوة التالية هي [31:50] السلامة. لدينا مجموعة [31:52] من القواعد [31:53] والإرشادات لكل [31:54] مستودع، والتي يجب أن [31:58] تتم المراجعة وفقًا [31:59] لها. على سبيل المثال، [32:01] إذا كنا نعدل نموذج [32:03] التعليقات، أو نغير [32:05] بعض إعدادات الأمان، [32:07] أو نقوم بإجراءات [32:09] تخريبية، فستختلف [32:11] المراجعة عما لو كنا [32:13] نغير نسخة زر فقط. [32:15] الخطوة التالية هي [32:16] المنطق. هذا هو الجزء [32:18] الأكثر تكلفة في هذه [32:19] العملية برمتها، وهو [32:21] أيضًا الجزء الذي [32:22] يُقضى فيه معظم الوقت. [32:23] في هذه المرحلة، يكون [32:25] الكود قد حصل على بيان [32:26] المشكلة، ويعرف الغرض [32:28] منها، ولديه الكود. [32:29] يبحث فقط عن الأخطاء. [32:31] وأخيرًا، لدينا [32:32] ممارسات قاعدة الكود. [32:35] نستخدم Ruby on Rails، [32:36] ونُعجب بتقاليدها، [32:37] لكن تطبيقنا قديم [32:39] نوعًا ما، ولدينا [32:40] العديد من التعديلات [32:41] التي اضطررنا إلى [32:43] إجرائها على مر السنين [32:44] لزيادة حجمه، أو ربما [32:46] لأننا نعمل على منصة [32:47] Planet Scale، وهناك أمور [32:49] محددة نحتاج أو نرغب [32:50] في القيام بها عند [32:52] التعامل معها. لدينا [32:53] الكثير من الإرشادات، [32:55] لكن واجهتنا مشكلة في [32:57] Bootstrap. لا أعرف إن كان [32:59] هذا ينطبق عليك أو على [33:01] أفضل المهندسين الذين [33:02] تعمل معهم، لكننا [33:04] جميعًا لسنا بارعين في [33:06] كتابة توثيق لأفضل [33:07] الممارسات. لذا، كان [33:10] لدينا نقص في [33:11] المعلومات والسياق في [33:13] هذه المرحلة. لكننا [33:15] أدركنا لاحقًا أن أفضل [33:17] مهندسينا هم أيضًا [33:19] الأفضل في مراجعة [33:20] طلبات السحب. لقد [33:22] راجعنا جميع طلبات [33:24] السحب التي تلقيناها [33:25] على Snowflake، مما مكّننا [33:27] من تحليل البيانات [33:29] بدقة. تمكّنا من [33:30] اختيار أفضل 10 إلى 20 [33:32] مهندسًا في كل مستودع، [33:34] ثم استخرجنا [33:35] ملاحظاتهم التي [33:36] قدموها في طلبات السحب [33:38] على مر السنين لنبدأ [33:40] بتوجيهاتنا. بعد ذلك، [33:42] قام هؤلاء المهندسون [33:43] بتنقيح مهاراتهم التي [33:45] استخدمناها في [33:46] المرحلة التالية. وقد [33:47] أسفر ذلك عن مراجعات [33:49] ممتازة حقًا. ثم كانت [33:51] المرحلة التالية: [33:52] حسنًا، أنتم تقومون [33:53] بمراجعات رائعة. هل [33:55] يمكنكم الموافقة على [33:56] الكود؟ وبالنسبة لنا، [33:58] نعم، يمكننا الموافقة [33:59] على الكود. لدينا [34:01] حوالي 500,000 طلب سحب في [34:03] قائمة نماذجنا، وقد [34:04] واجهنا العديد من [34:06] المشكلات والحوادث [34:07] المتعلقة بتغييرات [34:09] الكود على مر السنين. [34:13] لدينا مجموعة بيانات [34:15] غنية، وتمكّنا من بناء [34:17] قاعدة بيانات مرجعية [34:19] تضمّ ألف طلب سحب، حيث [34:24] تسبب تغيير ما في حدوث [34:25] مشكلة عند تطبيقه في [34:27] بيئة الإنتاج، أو حيث [34:28] أغفلها أحد الموظفين. [34:29] كنا نُجري عمليات [34:31] مراجعة متكررة حتى [34:32] يكتشف نظام المراجعة [34:33] الآلي جميع هذه [34:34] المشكلات. أردنا [34:37] التأكد من أن أي [34:39] موافقة نمنحها أفضل من [34:41] أي موافقة بشرية سابقة [34:43] . تكمن أهمية ذلك في [34:46] أنه عند إجراء أي [34:47] تغيير، سواءً في [34:49] النموذج أو غيره، يجب [34:51] إعادة اختبار كل شيء، [34:53] لأننا انتقلنا من [34:55] نموذج إلى آخر، إلى [34:57] نموذج أكثر تطورًا. [34:59] وقد ساءت بعض جوانب [35:00] هذا النموذج، وربما [35:02] اكتشف النظام مشكلات [35:03] وهمية لم تكن موجودة [35:05] أصلًا. لذا، كنا بحاجة [35:07] إلى إجراء اختبارات [35:08] رجعية في كل مرة [35:09] نُغيّر فيها نموذجًا [35:11] أو مُوجّهًا، مقارنةً [35:13] بكل ما أجريناه سابقًا [35:14] . ما هي نتائج هذه [35:15] الاختبارات؟ آه، آسف. [35:18] حسنًا، هذا ما يبدو [35:19] عليه الأمر في طلب [35:20] السحب. كان هذا عندما [35:21] كنتُ أُنشئ طلب سحب [35:22] لتحسين أداء شيء ما. [35:23] هذا هو التعليق الذي [35:25] سيظهر. أولًا، هذه [35:26] مرحلة التحقق من الصحة [35:28] . لاحظ النظام وجود [35:29] حالة تضارب في فحص "ensure [35:31] " وما إلى ذلك. لذا، لن [35:33] يُوافق على طلب السحب [35:35] بناءً على هذا. لدينا [35:36] فحص آخر، وهو عدد أسطر [35:38] التعليمات البرمجية [35:40] ذات المعنى، والذي [35:41] يتجاوز الحد الأقصى [35:43] البالغ 150 سطرًا. [35:44] بالنسبة لهذا [35:45] المستودع، حددنا [35:48] حاليًا 150 سطرًا كحد [35:49] أقصى للموافقة [35:51] التلقائية. وهنا، [35:52] يُوضح النظام أنك [35:53] ستحتاج إلى مُراجع [35:55] بشري للانتقال إلى [35:56] المرحلة التالية. هذا [35:58] مثير للاهتمام. لدينا [35:59] أيضًا حلقات حيث يقوم [36:01] المهندس الذي يُنشئ [36:02] التعليمات البرمجية [36:04] مع كلود بمراقبة مشكلة [36:05] GitHub. سيرى كلود هذه [36:07] المشكلة، ثم...سنبدأ [36:09] بإصلاح مشكلة التزامن [36:11] دون تدخل بشري. ثم ننشئ [36:13] طلبات سحب أخرى، ثم [36:15] نجري عملية دمج أخرى، [36:17] ثم نكرر هذه العملية. [36:19] لذلك، عندما كان لدى [36:21] المدققين العديد من [36:23] الأسئلة حول Track، كانت [36:25] هذه إجاباتي: إنه نظام [36:27] مستقل. فالمؤلف [36:29] والمُعتمد ما زالا [36:30] مستقلين تمامًا. لا [36:32] توجد لدينا طلبات سحب [36:34] أنشأها وكيل ووافق [36:35] عليها وكيل. لذا، يوجد [36:37] عنصر بشري في هذه [36:38] الحلقة لمعظم أنواع [36:39] طلبات السحب لدينا، [36:41] على الأقل في الوقت [36:42] الحالي. لذا، فهو نظام [36:44] موثق بالأدلة. فكل تلك [36:45] الأمور الأساسية، [36:46] وتشغيل اختبار [36:47] التكامل المستمر، وكل [36:48] شيء آخر، يتم إنجازه [36:49] بالكامل. كل شيء قابل [36:50] للتدقيق بالكامل. إنها [36:52] سلطة محدودة. لذا، لا [36:53] نستخدم هذا إلا في بعض [36:55] المستودعات، حيث [36:56] أجرينا كل هذه [36:57] الاختبارات السابقة، [36:58] ونحن واثقون جدًا من [37:00] النتائج. ويبقى العنصر [37:01] البشري مسؤولاً عن هذه [37:03] العملية برمتها. من [37:04] ينشئ طلب السحب، ومن [37:05] يديره، سواء كان كلود [37:07] أو غيره. لا يزال Codex أو [37:09] أي شخص آخر مسؤولاً عن [37:10] الموافقة هو المسؤول. [37:12] إذن، ما الذي تغير بعد [37:14] الإطلاق؟ كان متوسط [37:16] الوقت من المراجعة إلى [37:18] إنشاء طلب السحب ثم [37:20] دمجه 160 دقيقة مع [37:22] الموظفين. هذا الأمر [37:25] خفضه إلى 36 دقيقة. الآن [37:27] ، يصعب قليلاً [37:28] المقارنة لأن طلبات [37:29] السحب التي يوافق [37:30] عليها Shrek حاليًا هي [37:31] طلبات أقل خطورة من [37:32] تلك التي يوافق عليها [37:34] الموظفون، لكنها لا [37:35] تزال ذات دلالة. 40%من [37:36] جميع طلبات السحب [37:38] لدينا تتم الموافقة [37:39] عليها تلقائيًا. لذا، [37:41] هناك موظف واحد فقط في [37:42] العملية. معدل التراجع [37:45] هو 0.5%. من بين طلبات [37:47] السحب التي تمت [37:48] الموافقة عليها [37:50] تلقائيًا، يتم [37:51] التراجع عن طلب واحد [37:53] فقط من كل 200 طلب. معدل [37:55] التراجع مع الموظفين [37:56] يتجاوز 5%، ولكن مرة [37:57] أخرى، لا يمكن [37:58] المقارنة بشكل دقيق [37:59] لأن الموظفين يوافقون [38:01] أيضًا على تغييرات [38:02] أكثر خطورة. ومن [38:03] الأمور التي ستراها [38:04] كثيرًا على الإنترنت [38:05] هو أن الوكلاء ينشئون [38:07] طلبات سحب ضخمة، ضخمة [38:08] جدًا. طلبات السحب. وقد [38:10] وجدنا في الواقع عكس [38:11] ذلك. لقد كان هذا [38:12] بمثابة حافز اجتماعي [38:13] تقني لمحاولة حثّ [38:14] الناس على إنشاء طلبات [38:16] سحب أصغر، لأنه إذا [38:17] علموا أن الحد الأقصى [38:18] لعدد أسطر طلب السحب [38:19] لشريك هو 150 سطرًا، [38:21] فهذا بمثابة تعزيز [38:22] إضافي لمساعدة [38:23] المراجع على إنشاء طلب [38:24] سحب صغير. لذلك، انخفض [38:25] متوسط حجم طلب السحب [38:27] لدينا إلى حوالي 68 [38:28] سطرًا من التعليمات [38:29] البرمجية. من ناحية [38:31] أخرى، هناك الكثير من [38:32] الأشياء التي لم نحلها [38:34] . كما تحدثت عن ذلك في [38:35] البداية، مثل مسألة [38:37] نمو الاختبارات. هناك [38:38] الكثير من الأشياء غير [38:40] الضرورية فيها. ولدينا [38:41] أفضل موظفينا يعملون [38:43] على تنظيف هذه الأشياء [38:45] . لكن هذه مشكلة. نحن [38:48] جيدون جدًا في إجراء [38:49] الاختبارات، ويمكننا [38:50] التعامل معها، لكننا [38:51] نعتبر أيضًا أن هذا قد [38:52] يكون مؤشرًا على وجود [38:53] مشكلة. ربما يحدث [38:54] انحراف معماري. لو [38:56] تحدثت معي قبل عام [38:57] ورأيت كمية التعليمات [38:58] البرمجية والتغييرات [38:59] التي كنا نجريها [39:00] داخليًا، كنت سأقول: " [39:01] يا إلهي، سنحصل على [39:03] كرة كبيرة من الطين". [39:04] كنتُ قلقًا بعض الشيء. [39:05] في الواقع، لم يحدث [39:07] ذلك. انخفضت الحوادث، [39:09] وتحسنت جودة المنتج، [39:10] وقلّت الفترة الزمنية [39:12] بين قرارنا بتطوير [39:14] ميزة جديدة وطرحها في [39:15] بيئة الإنتاج [39:16] واستخدامها من قِبل [39:18] العملاء. أصبحنا نُصدر [39:20] الميزات بشكل أسرع، [39:21] ونُصدر المزيد منها في [39:23] نفس الوقت. لذا، يبدو [39:25] أن كل شيء على ما يُرام [39:27] . ما زلتُ قلقًا بعض [39:28] الشيء، لكن ربما سيبقى [39:30] الوضع على ما يُرام [39:31] دائمًا. أما بالنسبة [39:32] لوقت إعادة تشغيل [39:33] الأسطول، فعندما نقوم [39:34] بالتراجع التلقائي، [39:36] يستغرق الأمر حوالي [39:37] ثلاث أو أربع دقائق. [39:38] ربما سنُجري تحسينات [39:40] على مسار العمل، [39:41] فبدلًا من استخدام [39:43] نظامي Passenger و Ninehorn [39:44] الحاليين، سنُنشئ [39:46] نظامنا الخاص لزيادة [39:48] هذه المدة، لأنه في [39:49] بعض الأحيان، إذا كان [39:51] التطبيق مُعطلًا [39:52] وتريد التراجع، فلن [39:54] تُبالي بسلاسة [39:55] عملياتك، بل ستُريد [39:57] فقط إيقافها. لذلك، [39:59] نعتقد أن هناك طريقة [40:00] لتحسين هذه العملية. [40:02] همم، بشكل فوري. لكنني [40:04] سأنهي هذا. إذن، كل [40:06] تغيير يبدأ بفرضية، ثم [40:08] القيام بشيء ما، [40:09] فالإنتاج يوفر سلوك [40:11] الإنتاج الذي يوفر [40:12] الدروس المفيدة، ثم [40:14] يجب أن يتضمن التغيير [40:16] التالي تلك التجربة. [40:18] لذا، مهمتنا هي جعل [40:20] هذه الدورة بأسرع ما [40:22] يمكن، وأن ننظر