Tìm hiểu về mô hình Delivery Driven Development (DDD) trong Phát triển phần mềm

Giới Thiệu

Mục đích của bài viết này là mô tả một phương pháp phát triển mới gọi là "Delivery Driven Development" hoặc gọi tắt là DDD. Phương pháp này hiện đang được sử dụng thành công rộng rãi trong nhiều tổ chức.

Delivery Driven Development (DDD) không thay thế các phương pháp hiện tại như Test Driven Development (TDD) hay Agile, mà thay vào đó bổ sung và tăng cường hiệu suất của chúng.

Mục đích của phương pháp này là nâng cao tầm quan trọng của việc giao hàng để nó trở thành hơn là một ý nghĩa sau cùng trong quá trình phát triển. Thay vào đó, delivery channel trở thành sự xem xét đầu tiên sau giai đoạn Phân tích và Thiết kế ban đầu của Quy trình Phát triển Phần mềm (SDLC).

Lịch Sử

Trong thập kỷ 90 và thậm chí vào đầu thập kỷ 2000, các loại delivery channel thường bị hạn chế. Không có Github, Azure, hoặc AWS và có rất ít ví dụ về cloud hosting. Phần mềm thường được lưu trữ on-premises với một số ví dụ về cơ sở hạ tầng chia sẻ. Hơn nữa, các rủi ro như an ninh cũng đã tăng lên.

Mặc dù một công ty có thể có nhiều khách hàng, sự biến động trong các kênh giao hàng và sự phức tạp trong quá trình giao hàng ngày càng nhiều hơn so với hiện tại.

Trong quá khứ, nhiều công ty đã áp dụng TDD và tùy thuộc vào dự án, sử dụng phương pháp phát triển theo mô hình Waterfall hoặc Agile. Những thực hành này thường được áp dụng với mức độ thành công khác nhau.

Cho dù đây có phải là một phương pháp đánh giá chính xác hay không, cái thước thường được sử dụng để xác định sự thành công hay thất bại của những thực hành này là kết quả của quá trình delivery.

Điều này tạo ra sự mơ hồ trong quá trình phát triển, vì kdelivery channel không được kiểm soát trực tiếp bởi TDD, Waterfall, Agile hay bất kỳ phương pháp phổ biến nào khác.

Đối Tượng Mục Tiêu

Như hầu hết các phương pháp khác, phương pháp này sẽ không phù hợp cho mọi công ty hay dự án. Trên thực tế, trừ khi bạn triển khai cho nhiều khách hàng, mỗi khách hàng có các channel và logic triển khai (logic eploy) khác nhau, thì lợi ích của phương pháp này có thể không ngay lập tức rõ ràng.

Ví dụ, một nhà cung cấp phần mềm bằng phương pháp này được triển khai một cách thành công ít nhất có 100 khách hàng. Mỗi khách hàng có ít nhất 5 môi trường và 3 mục tiêu triển khai trong mỗi môi trường. Một số khách hàng lưu trữ giải pháp on-premises và một số khác sử dụng cơ sở hạ tầng chia sẻ (shared infrastructure) hoặc cloud. Hơn nữa, mỗi khách hàng có các mức độ bảo mật khác nhau về hình thức phần cứng, chính sách và quy tắc cũng khác nhau hoàn toàn.

Các Bước trong Delivery Driven Development (DDD)

DDD bao gồm năm bước Analysis, Design, Implementation, Testing và Delivery.

Channel Analysis

Channel Analysis là bước "Where". Nó liên quan đến việc xác định điểm đến của các tài nguyên triển khai.

Từ "Destinationn" là một thuật ngữ rất rộng và được thiết kế để bao gồm nhiều khía cạnh. Đối với nhiều công ty, bước này sẽ bao gồm xem xét về:

Nuget
MyGet
npm
Windows FileSystem
Windows Web App
Windows Service
Azure SQL
Azure Web App
Azure App Service
SqlServer
Octopus Deploy (Destination cho các gói triển khai)

Channel Design

Channel Design là bước "How". Nó liên quan đến việc xác định cách các tài nguyên triển khai sẽ được delivery.

Những ngày sử dụng MSI để triển khai các giải pháp lớn, phức tạp đến một nhóm máy chủ, dịch vụ và kho lưu trữ đang gần kết thúc.

Trong hầu hết các trường hợp, quá trình Build và Release sẽ giữ nguyên chủ yếu trên tất cả các dự án. Tuy nhiên, quá trình Deploy có thể thay đổi dựa trên cơ sở hạ tầng, nền tảng và mô hình bảo mật của khách hàng. Đối với nhiều công ty, bước này sẽ bao gồm xem xét về:

Target Environments, ví dụ: Dev, UAT, Training, Staging, Prod
Target Machines
Vai Trò Target Machines, ví dụ: Windows Server, Application Server, Database Server
Trình Cân Bằng Tải (Load Balancer)
Kế Hoạch Disaster Recovery (DR)
Phiên Bản Windows, SQLServer và SharePoint
Windows hoặc Token based Authentication
Quy tắc Firewall và Group Policy Windows
Trong trường hợp của Octopus Deploy, loại Tentacle được sử dụng. Điều này có thể thay đổi tùy thuộc vào môi trường.

Channel Implementation

Channel Implementation là bước "Doing". Nó có thể liên quan đến cấu hình một hoặc nhiều channel. Bước này chủ yếu được thúc đẩy bởi bước Channel Design và các công cụ có sẵn.

Các công cụ thường được sử dụng để thiết lập kênh triển khai bao gồm Team Foundation Server (TFS) và Octopus Deploy. Đối với nhiều công ty, bước này sẽ bao gồm xem xét về:

Làm việc chặt chẽ với khách hàng để đảm bảo máy mục tiêu có thể giao tiếp với máy chủ triển khai, ví dụ: Octopus Deploy và Chocolatey
Thiết lập kho lưu trữ, ví dụ: MyGet & npm
Cấu hình Môi trường thông qua một cổng quản lý cấu hình trung tâm, ví dụ: Octopus Deploy

Channel Testing

Channel Testing là bước "Fixing". Nó liên quan đến việc kiểm thử toàn bộ hệ thống của kênh triển khai. Dự kiến rằng bước này sẽ xác định bất kỳ vấn đề nào có thể đe dọa việc triển khai thành công. Đối với nhiều công ty, bước này sẽ bao gồm xem xét về:

Tài khoản Dịch vụ, ví dụ: tài khoản dịch vụ Octopus Tentacle, tài khoản Dịch vụ Web và tài khoản Dịch vụ Windows
Cấu hình Môi trường
Quyền truy cập và tải về từ Chocolatey
Quyền cập nhật Registry
Quyền tạo và cấu hình ứng dụng web IIS
Quyền cài đặt Windows Services
Quyền cấu hình MSDTC
Quyền tạo Cơ sở dữ liệu SQL Server
Quyền chạy un-signed PowerShell scripting
Quyền cài đặt và kích hoạt SharePoint Solutions cho SharePoint Page

Channel Delivery

Channel Delivery là bước cuối cùng nhưng quan trọng. Nó liên quan đến triển khai thực tế một Release hoặc Release Candidate (RC).

Bước này cũng nên bao gồm một bài kiểm tra toàn diện của một Release trong môi trường đích trước khi chính thức được giao cho khách hàng để thử nghiệm chấp nhận người dùng (UAT).