Làm cách nào để thuyết phục các nhà phát triển bắt đầu sử dụng tính năng bật cờ?

Giả sử rằng các cờ chuyển đổi tính năng là một ý tưởng tốt và nên được triển khai thành mã mà các nhà phát triển viết. Ví dụ, Etsy thề với họ như một phần chính trong văn hóa của họ .

Một cách tốt để thuyết phục (và thực thi) các nhà phát triển bắt đầu sử dụng các tính năng bật cờ là gì?

Thông tin thêm về các tính năng chuyển đổi cờ tính năng được giải thích trong Q: Cách sử dụng các tính năng chuyển đổi cờ tính năng , Q: Các tính năng chuyển đổi cờ đặc trưng và rất rộng rãi trong bài viết của Pete Hodgson về chủ đề trên blog của Martin Fowler .

Các tính năng bật tắt là một thông lệ phổ biến trong phát triển tốc độ cao vì chúng phát triển cặp đôi từ khi phát hành. Các nhóm phát triển có thể "phát hành mềm" một tính năng mới cho sản xuất, ở trạng thái bị vô hiệu hóa. Điều này cho phép tính năng được phát hành bất cứ lúc nào. Nếu tính năng này phụ thuộc vào công việc hoặc chuẩn bị khác, thì nó không phải đợi bản phát hành chính được đưa vào sản xuất.

Theo như các nhà phát triển "thuyết phục" sử dụng chúng, đó là một bài tập trong việc tạo ra sự tự do mà nó mang lại. Kinh nghiệm của tôi là nó không phải là một khó khăn để bán cho các nhà phát triển. Đó là quản lý có xu hướng miễn cưỡng thử những điều mới. Thử đi:

• Tìm một khung chuyển đổi tính năng. Quản lý / doanh nghiệp có thể dễ dàng hơn để thử một cái gì đó được hỗ trợ bởi một hệ thống chung
• Khởi đầu nhỏ. Giới thiệu hệ thống chuyển đổi trên cơ sở dùng thử cho một tính năng sẽ thể hiện tiện ích của nó.
• Thể hiện khả năng chuyển đổi để thực hiện kiểm tra A / B. Kích hoạt chuyển đổi cho một tập hợp con của trang trại web của bạn, sau đó thu thập số liệu về hành vi. Sự khác biệt nhỏ trong cách bố trí trang đã được chứng minh là có ảnh hưởng lớn đến doanh thu cho các ứng dụng bán lẻ (ví dụ: Ebay, Amazon)

Trong một thế giới lý tưởng tôi nghĩ bạn tung ra một bản dựng mới và bất ngờ! Không có gì thay đổi. Điều này là do tất cả các tính năng mới của bạn nằm phía sau các công tắc tắt khi tắt.

Sau khi triển khai, bạn xác minh rằng dịch vụ triển khai của bạn vẫn hoạt động, điện thoại sẽ không đổ chuông nữa (trừ khi điện thoại đổ chuông là mục đích của bạn), v.v. Khi bạn quay lại hoạt động ổn định đã biết, bạn bắt đầu bật và xác minh các tính năng mới được triển khai của bạn.

Bây giờ cho câu trả lời của bạn: Làm thế nào bạn muốn làm việc trong một nhóm mà thực hiện cuộc gọi thực tế là không có trí tuệ và người dùng của chúng tôi yêu chúng tôi vì các trang web và dịch vụ của chúng tôi ổn định vững chắc?

Đó là đội tôi muốn làm việc.

Bạn có thể dừng đọc ở đây nếu bạn muốn.

Đặt mọi thứ đằng sau một công tắc tính năng có vẻ như nó có thể dẫn đến mã spaghetti ở mọi nơi. Nếu bạn sử dụng IoC và có thể chọn giữa vNow / vNext / vPreingly thì điều đó sẽ giúp duy trì cấu hình của bạn. Có nhiều kiểm tra hơn, có nhiều lớp hơn (thành phầnV1, thành phần 2, thành phần 3, v.v.) nhưng bạn thực sự có một hệ thống ổn định hơn? Làm sao? vNext có mạnh không? Chuyển về vNow với tháp điều khiển của bạn. Được một tuần và vNow có một lỗi tinh vi? Điều tương tự - quay trở lại vPreingly một cách dễ dàng.

Không rắc rối, không lo lắng, không mất ngủ, không căng thẳng.

Đây không phải là một giấc mơ ống. Tôi đã từng làm việc ở đó. Ước gì tôi có thể bán cái này cho đội hiện tại của mình.

Một môi trường phát triển tốc độ cao thành công thường dựa vào một hệ thống tự động khá nghiêm ngặt liên quan đến việc xác minh chất lượng với việc phát hiện và từ chối các thay đổi bị lỗi gây ra hồi quy.

Các tính năng bật tắt cung cấp khả năng cam kết ngay cả trong quá trình thực hiện, các thay đổi chưa được kiểm tra mà không bị từ chối vì gây ra hồi quy trong nhánh tích hợp. Điều này tạo nên một động lực rất tốt để giới thiệu tính năng này bật rất sớm trong vòng đời của tính năng.

Một trong những nhược điểm của việc đi chệch khỏi CI thực sự và phát triển tính năng di chuyển trên các nhánh tính năng là thiếu sự khuyến khích như vậy. Việc thêm tính năng chuyển đổi sau này, khi hợp nhất nhánh tính năng vào nhánh tích hợp thường khó khăn hơn, giống như bất kỳ tích hợp muộn nào.

Các nhà phát triển (và thường là các nhà quản lý phát triển) thường tìm kiếm hai kết quả liên quan đến khung: dễ quản lý và tốc độ triển khai. Bạn muốn gửi mã nhanh hơn, và dễ dàng hơn.

Cung cấp bằng chứng rằng phương pháp này hoạt động; hãy thử xây dựng một POC nhỏ bằng cách sử dụng các cờ tính năng so với cách cũ. Nghiên cứu trường hợp ít quan trọng đối với người chiến thuật (nhà phát triển \ kỹ sư) so với người chiến lược (quản lý cấp trung \ nhà thiết kế sản phẩm).

Lý do để có tính năng bật tắt không phải là điều để các nhà phát triển quyết định. Đây là điều để chủ sở hữu sản phẩm quan tâm. Các nhà phát triển cho phép thay đổi này theo cách bền vững và an toàn nhất. Tôi phê bình câu hỏi này rất nhiều.