Với cuốn Doanh nghiệp Tinh gọn, các bạn có thể nắm bắt được cách thức vận dụng triết lý Tinh gọn trên bình diện toàn bộ doanh nghiệp để cải tiến, đổi mới hoạt động sản xuất kinh doanh của doanh nghiệp từ quản trị chiến lược, quản trị tài chính, quản trị hoạt động tác nghiệp, quản lý danh mục đầu tư , đến quản lý rủi ro, tái cấu trúc bộ máy, hệ thống kinh doanh. Các tác giả đã cố gắng xây dựng một bộ khuôn mẫu và những nguyên tắc theo triết lý loại bỏ lãng phí của hệ thống, tập trung vào các quy trình mang lại giá trị gia tăng cho tổ chức hay doanh nghiệp. Từ đó, họ cũng nhấn mạnh rằng thách thức lớn nhất của việc cải tiến doanh nghiệp không nằm ở hệ thống công nghệ hay thiết bị mà nằm chủ yếu ở nhận thức đổi mới tư duy của con người trong tổ chức.

Những doanh nghiệp lớn đã dùng kỹ thuật tinh gọn để xét lại mọi thứ: từ quản lý tài chính đến vận hành; từ kiến trúc hệ thống đến văn hóa tổ chức để theo đuổi sự tăng trưởng vượt trội bằng cách nào?

  • Bằng cách sử dụng kỹ thuật Tinh gọn để tập trung vào con người và độ nhóm ở mọi cấp độ.
  • Bằng cách tiếp cận phương thức giải quyết vấn đề kiểu thử nghiệm, khám phá ra các giải pháp, kiểm chứng các giả thiết và nhận phản hồi từ người dùng thật sự.
  • Bằng cách dẫn dắt và quản lý các chương trình quy mô lớn thông qua việc trao quyền cho nhân viên, gia tăng tốc độ và chất lượng giao hàng đồng thời hạ thấp chi phí.
  • Bằng cách thực thi những ý tưởng dựa trên kỹ thuật khởi nghiệp tinh gọn ngay cả trong những môi trường phức tạp.

Cùng nhiều cách thức mới mẻ và hiệu quả khác nữa…

Trích đoạn sách hay

TIẾP NHẬN CÁC BIỆN PHÁP KỸ THUẬT TINH GỌN

Hãy ngừng phụ thuộc vào các cuộc điều tra hàng loạt để đảm bảo đạt được chất lượng sản phẩm. Hãy cải thiện tiến trình và nâng cao chất lượng sản phẩm ngay từ bước đi đầu tiên.

− W. EDWARDS DEMING

Khả năng cải tiến hiệu quả phụ thuộc vào việc bạn có thể thường xuyên kiểm thử các ý tưởng với những người dùng thực sự hay không. Cần lưu ý, mức độ chúng ta có thể học hỏi, cập nhật sản phẩm hoặc nguyên mẫu dựa trên phản hồi và tái kiểm thử là một lợi thế cạnh tranh mạnh mẽ. Đây là tuyên bố giá trị của các biện pháp kỹ thuật tinh gọn mà chúng tôi mô tả trong chương này. Andy Hertzfeld, một kỹ sư làm việc cho Apple Macintosh khi mới thành lập, nhấn mạnh rằng:

“Thay vì tranh luận về các ý tưởng phần mềm mới, chúng ta thực sự phải kiểm thử chúng bằng cách viết nhanh ra những nguyên mẫu, giữ lại các ý tưởng tốt nhất và loại các ý tưởng khác. Chúng ta phải luôn thực hiện điều gì đó thể hiện tư duy tốt nhất của mình ở một thời điểm nào đó.”

Trong nhiều tổ chức, triển khai phần mềm vào một môi trường kiểu sản xuất tích hợp vẫn là một tiến trình mất đến vài ngày hoặc thậm chí nhiều tuần. Trong khi đó, các tổ chức coi phần mềm là một lợi thế cạnh tranh chứ không phải khoản đầu tư cần thiết nhưng không thú vị gì thì lại thường đầu tư đáng kể vào việc giảm thời lượng sản xuất. Ví dụ minh họa về những gì có thể ở quy mô phù hợp là trong tháng 5 năm 2011, Amazon đã đạt độ dài thời gian từ khi kích hoạt đến khi đưa vào các hệ thống sản xuất là 11,6 giây, tốc độ lên tới 1.079 lần kích hoạt mỗi giờ kết hợp với hàng nghìn dịch vụ, trong đó có nền tảng của Amazon. Có những lần kích hoạt đã tác động đến 10.000 trang chủ. Tất nhiên là Amazon cũng phải chịu sự chế tài của các quy định như là Đạo luật Sarbanes-Oxley1 và Tiêu chuẩn PCI-DSS2. Lý do chính thúc đẩy Amazon đầu tư vào khả năng này là khiến nó cực rẻ và ít rủi ro cho công nhân khi thiết kế và tiến hành các thử nghiệm trực tuyến thất bại-an toàn được mô tả trong Chương 9 để thu thập dữ liệu từ người dùng thực. Trong nhiều trường hợp, tiến hành một cuộc thử nghiệm không buộc phải trải qua một tiến trình yêu cầu thay đổi quan liêu. Điều này cho phép các nhóm phân phối liên chức năng của Amazon có khả năng kiểm thử các ý tưởng độc đáo nhưng vẫn cảm thấy an toàn khi hiểu rằng nếu có gì sai lầm, họ có thể ngừng thử nghiệm mà chỉ tác động đến một lượng nhỏ người dùng trong một khoảng thời gian rất ngắn.

1 Là một trong những luật căn bản của nghề kế toán, kiểm toán, được ban hành tại Hoa Kỳ năm 2002. Mục tiêu chính nhằm bảo vệ lợi ích của các nhà đầu tư vào các công ty đại chúng bằng cách buộc các công ty này phải cải thiện sự đảm bảo và tin tưởng vào các báo cáo, các thông tin tài chính công khai. (ND)

2 Payment Card Industry Data Security Standard là một tiêu chuẩn an ninh thông tin bắt buộc dành cho các doanh nghiệp lưu trữ, truyền tải và xử lý thẻ thanh toán quản lý bởi năm tổ chức thanh toán quốc tế như Visa, MasterCard, American Express, Discover và JCB. (ND)

Mặc dù tên gọi là như vậy nhưng Phân phối Liên tục không chỉ là việc triển khai sản xuất nhiều lần mỗi ngày. Mục đích của Phân phối Liên tục là làm cho việc triển khai công việc trong các khối nhỏ diễn ra an toàn và kinh tế. Nhờ vậy, thời lượng sản xuất sẽ ngắn hơn, chất lượng cao hơn và chi phí thấp hơn. Vì những lý do đó, nhóm HP FutureSmart đã tái cấu trúc chương trình cơ sở để giảm lộn xộn và giảm thiểu thời lượng từ khi chấp nhận mã đến phần mềm đã được thẩm định và có thể lưu hành. Cuối cùng, Phân phối Liên tục giúp kích hoạt việc triển khai sản xuất an toàn, đều đặn chứ không gây ra thử thách lâu dài và đau đớn buộc bạn phải làm thêm giờ để giải quyết.

Chương này hướng đến những độc giả có mong muốn tìm hiểu về các nguyên tắc và biện pháp Phân phối Liên tục. Đối với những người chỉ cần một bức tranh khái quát, chúng tôi có trình bày một bản tóm tắt chuyên đề về các biện pháp kỹ thuật tinh gọn trong phần sau. Nếu vậy, độc giả có thể bỏ qua phần này để đi đến phần cuối của chương.

NỀN TẢNG CỦA PHÂN PHỐI LIÊN TỤC

Phân phối Liên tục là khả năng đưa những thay đổi – những thử nghiệm, tính năng, sự thay đổi phần cứng, việc sửa lỗi – vào quá trình sản xuất hoặc đến tay một vài người dùng một cách an toàn, nhanh chóng và bền vững. Chúng ta hãy xem xét từng yêu cầu này.

An toàn

Để đảm bảo việc triển khai an toàn, chúng tôi xây dựng một đường ống triển khai (deployment pineline3) để đưa mỗi sự thay đổi được đề xuất vào một bộ gồm vài loại kiểm thử tự động khác nhau, sau đó tiến hành thẩm định thủ công bằng kiểm thử khám phá và kiểm thử tính hữu dụng. Sau đó, chúng ta tiến hành kiểm thử theo chuỗi và kiểm thử lần cuối đối với các kiến trúc đã được thẩm định, cuối cùng đưa các kiến trúc đó vào sản xuất, phân phối hoặc tải lên một kho ứng dụng (phụ thuộc vào loại phần mềm). Một mục đích chính của đường ống triển khai là phát hiện và bác bỏ những thay đổi quá rủi ro, hạn chế suy thoái hoặc đưa chúng ta vượt ra khỏi khuôn khổ hiệu năng được chấp nhận. Một sản phẩm phụ của việc thực hiện đường ống triển khai là chúng ta theo dõi được từng sự thay đổi được đưa ra ở đâu, những kiểm thử nào đã được thực hiện, nó đã trải qua những môi trường nào, ai triển khai… Những thông tin này không có giá trị để làm bằng chứng về sự tuân thủ của nhân viên.

3 Deployment Pipeline chia quy trình chuyển giao phần mềm thành các giai đoạn; mỗi giai đoạn có mục tiêu xác minh chất lượng của các tính năng mới từ một góc độ khác nhau để kiểm định chức năng và tránh lỗi ảnh hưởng đến người dùng. Pipeline sẽ cung cấp phản hồi cho nhóm về việc cung cấp tính năng mới. Ở góc độ trừu tượng hơn, deployment pipeline là quy trình để chuyển phần mềm từ kiểm soát phiên bản đến tay người dùng. Mỗi thay đổi đến phần mềm sẽ đi qua một quy trình phức tạp để được phát hành. (ND)

Một cách nhanh chóng

Chúng ta phải không ngừng giám sát và giảm thời lượng đưa những thay đổi đến tay người dùng. Mary và Tom Poppendieck đặt câu hỏi: “Tổ chức của bạn mất bao lâu để triển khai một sự thay đổi chỉ liên quan đến một dòng mã duy nhất?” Chúng ta giảm thời lượng sản xuất bằng cách đơn giản và tự động hóa tiến trình xây dựng, triển khai, kiểm thử và lưu hành. Chúng ta phải có khả năng điều chỉnh các môi trường kiểm thử theo yêu cầu, triển khai các gói phần mềm trong các môi trường đó và nhanh chóng tiến hành đồng thời một số loại thử nghiệm tự động toàn diện trên hệ thống máy tính. Sử dụng tiến trình này, bạn có thể thêm tự tin rằng phần mềm của chúng ta có thể đưa ra lưu hành. Về cơ bản, những việc này liên quan đến cấu trúc (hoặc tái cấu trúc) sử dụng khả năng kiểm thử và triển khai của bạn. Một tác dụng khác quan trọng của việc này là nhóm sản phẩm có thể nhanh chóng nhận được phản hồi về chất lượng công việc của mình và nhanh chóng phát hiện các vấn đề ngay khi chúng được đưa ra chứ không phải đợi đến giai đoạn tích hợp và kiểm thử sau đó, khi mà bạn chỉ có thể giải quyết chúng với chi phí đắt đỏ hơn nhiều.

Bền vững

Trọng tâm của tất cả những việc này là làm cho Phân phối Liên tục khả thi ở khía cạnh kinh tế khi triển khai theo các nhóm nhỏ. Lý do người ta hiếm khi đưa ra các nhóm làm việc lớn là vì tích hợp các hoạt động phân phối là việc khó khăn và đắt đỏ. Câu thần chú của Phân phối Liên tục chính là: “Nếu nó khó khăn, hãy thực hiện nó thường xuyên hơn và sẵn sàng đối mặt với nó.” Nếu việc tích hợp, kiểm thử và triển khai là việc khó khăn, chúng ta cần thực hiện chúng bất cứ khi nào có ai đó đưa bất kỳ điều gì thành phiên bản kiểm soát. Điều này làm bộc lộ sự lãng phí và thiếu hiệu quả trong tiến trình phân phối của chúng ta, qua đó chúng ta có thể giải quyết những vấn đề đó thông qua cải tiến liên tục. Tuy nhiên, để việc tổ chức công việc theo các nhóm nhỏ có hiệu quả kinh tế, chúng ta cần đầu tư tăng cường kiểm thử và tự động triển khai và tạo dựng một kiến trúc hỗ trợ cho điều đó.

Có hai nguyên tắc vàng về Phân phối Liên tục mà mọi người phải tuân thủ:

1. Nhóm không được phép nói rằng họ đã “hoàn thành” bất kỳ phần công việc nào cho đến khi ai đó tìm thấy mã của họ trên trục quản lý phiên bản (đối với nhiều dịch vụ máy chủ4, vị trí của trục này thậm chí còn cao hơn – “hoàn thành” có nghĩa là đã triển khai sản xuất). Trong cuốn Khởi nghiệp tinh gọn, Eric Ries lập luận rằng đối với các tính năng mới mà không phải là những yêu cầu đơn giản của người dùng, nhóm cũng phải tiến hành các thử nghiệm đối với người dùng thực để đánh giá liệu tính năng đó có đem lại kết quả mong muốn không.

4 Hosted services là các hệ thống và chức năng IT thuê ngoài. Nhà cung cấp dịch vụ máy chủ sở hữu, giám sát cơ sở hạ tầng, phần mềm và các nhiệm vụ điều hành đồng thời khiến hệ thống sẵn sàng cho các khách hàng, thông thường là qua Internet. (ND)

2. Nhóm phải ưu tiên duy trì hệ thống trong trạng thái sẵn sàng triển khai khi cần thực hiện một công việc mới. Điều này có nghĩa là nếu ở bất kỳ điểm nào mà chúng ta không tự tin là có thể đưa bất kỳ điều gì vào trục quản lý phiên bản và phân phối tới người dùng thông qua một tiến trình tự động và “nhấn nút”, thì chúng ta cần ngừng làm việc và giải quyết vấn đề đó.

Chúng ta cần khẳng định rằng việc kiên định thực hiện các bước này là điều khó khăn và đòi hỏi tính kỷ luật – ngay cả đối với các nhóm nhỏ và nhiều kinh nghiệm.

BÍ QUYẾT

Giúp bạn hiểu rõ hơn về định nghĩa của “Hoàn thành”

Các nhà quản lý HP FutureSmart có một nguyên tắc đơn giản để thúc đẩy thực hiện các nguyên tắc vàng này. Bất cứ khi nào có ai đó muốn chứng minh một tính năng mới (tức là được yêu cầu phải có thể tuyên bố rằng việc đó đã “hoàn thành”), họ sẽ hỏi liệu mã đó đã được tích hợp vào trục chưa, và liệu chức năng mới có được chứng minh trong môi trường tương tự như môi trường sản xuất bằng cách thực hiện các kiểm thử tự động hay không. Người đó chỉ có thể tiếp tục chứng minh tính năng mong muốn nếu câu trả lời cho cả hai câu hỏi trên là “có”.

Trong Chương 6 chúng ta đã bàn về việc nhóm HP FutureSmart đạt được sự gia tăng mạnh mẽ về chất lượng, sản lượng và giảm chi phí. Những cải tiến này có được là nhờ HP FutureSmart đã coi các nguyên tắc Phân phối Liên tục là trọng tâm của hoạt động tái xây dựng của mình. Nhóm loại bỏ các giai đoạn tích hợp và kiểm thử khỏi tiến trình phát triển phần mềm bằng cách đưa việc tích hợp và kiểm thử vào công việc thường nhật của mình. Bạn cũng có thể nhanh chóng chuyển ưu tiên để kịp thời đáp ứng những nhu cầu thay đổi của thị trường sản phẩm và người dùng:

Chúng tôi biết chất lượng của mình trong vòng 24 giờ sau khi thực hiện bất kỳ việc gì trong hệ thống… và chúng tôi có thể kiểm thử rộng rãi ngay cả đối với những thao tác nhỏ vào phút cuối để đảm bảo rằng việc sửa lỗi không gây ra những thất bại không mong muốn. Hoặc chúng tôi có thể đưa ra những tính năng mới ngay sau khi tuyên bố rằng “chức năng hoàn tất” – hoặc trong một số trường hợp đặc biệt, ngay sau khi tuyên bố về một phiên bản dùng thử.

Chúng ta hãy xem xét các cơ cấu kỹ thuật đã giúp cho nhóm HP FutureSmart đạt mức tăng sản lượng gấp tám lần.

TÍCH HỢP LIÊN TỤC VÀ KIỂM THỬ TỰ ĐỘNG

Trong nhiều nhóm phát triển, các nhân viên thường làm việc rất lâu trong nhánh kiểm soát phiên bản. Đối với các nhóm nhỏ làm việc tập trung và có kinh nghiệm, điều này có thể hiệu quả. Tuy nhiên, kết quả tất yếu của việc áp dụng tiến trình này là hiện tượng “địa ngục tích hợp” (integration hell5), tức là khi mà các nhóm mất nhiều ngày hoặc nhiều tuần vào việc tích hợp và ổn định các nhánh này để phát hành mã. Giải pháp là tất cả các lập trình viên cần làm việc ngoài trục và tích hợp công việc của họ vào trục ít nhất mỗi ngày một lần. Để làm được như vậy, họ cần học cách chia các phần việc lớn thành các bước tiến nhỏ giúp duy trì khả năng làm việc và phát hành của trục.

5 Địa ngục tích hợp nói đến một thời điểm trong sản xuất, khi mà các thành viên trong một nhóm phân phối tích hợp mã cá nhân của họ. Trong môi trường phát triển phần mềm truyền thống, tiến trình tích hợp này hiếm khi êm ả và liền mạch mà thường phải mất nhiều giờ hoặc thậm chí nhiều ngày sửa mã đó để nó có thể tích hợp hoàn toàn. (ND)

Chúng ta thẩm định khả năng làm việc của trục bằng cách thiết kế ứng dụng hoặc dịch vụ mỗi khi có một thay đổi với trục được đưa ra trong quản lý phiên bản. Chúng ta cũng kiểm thử theo đơn vị đối với phiên bản mã mới nhất, và chuyển phản hồi cho nhóm trong một vài phút nếu tiến trình thiết kế hoặc kiểm thử thất bại. Khi đó, nhóm phải giải quyết vấn đề hoặc – nếu vấn đề không thể giải quyết được trong một vài phút – thì phải khôi phục sự thay đổi đó. Như vậy, chúng ta đảm bảo rằng phần mềm của mình luôn trong trạng thái làm việc trong suốt tiến trình phát triển.

Tích hợp liên tục là biện pháp làm việc theo các nhóm nhỏ và dùng kiểm thử tự động để phát hiện và loại bỏ những thay đổi có thể dẫn tới sự thụt lùi. Theo quan điểm của chúng tôi, đây là biện pháp kỹ thuật quan trọng nhất theo tiêu chuẩn linh hoạt, giúp hình thành nền tảng cho phân phối liên tục với yêu cầu là mỗi thay đổi phải đảm bảo khả năng phát hành cho mã trên trục. Tuy nhiên, các nhóm không quen với tích hợp liên tục sẽ thấy khó có thể chấp nhận biện pháp này.

Theo kinh nghiệm của chúng tôi, mọi người có xu hướng chia thành hai trường phái: những người không thể hiểu làm thế nào mà điều đó lại khả thi (đặc biệt là ở quy mô phù hợp) và những người không thể tin rằng người ta lại có cách làm việc nào khác. Chúng tôi đảm bảo với các bạn rằng điều đó là có thể, cả ở quy mô nhỏ và lớn, bất kể lĩnh vực của bạn là gì.

Trước tiên chúng ta hãy giải quyết vấn đề quy mô với hai ví dụ. Thứ nhất, trường hợp nghiên cứu HP FutureSmart chứng minh tính hiệu quả của tích hợp liên tục với một nhóm phân tán gồm 400 người làm việc trong một hệ thống nhúng. Thứ hai, chúng tôi nhận thấy gần như tất cả trong số hơn 10.000 lập trình viên của Google phân tán tại hơn 40 văn phòng khắp thế giới cùng làm việc bên ngoài một cây mã chuẩn. Tất cả những người làm việc bên ngoài cây mã này phát triển và phát hành ngoài trục, và tất cả các kiến trúc đều được tạo ra từ nguồn. Có từ 20 đến 60 sự thay đổi mã được đưa ra mỗi phút, và 50% những thay đổi về mã nền mỗi tháng. Các kỹ sư Google đã xây dựng một hệ thống tích hợp liên tục mạnh mẽ, tại thời điểm năm 2012 đã vận hành hơn 4.000 cấu trúc và 10 triệu bộ kiểm thử (xấp xỉ 60 triệu lần kiểm thử) mỗi ngày.

Tích hợp liên tục không chỉ khả dĩ đối với các nhóm lớn và phân tán – nó còn là tiến trình duy nhất được đánh giá là tăng trưởng hiệu quả mà không phải trải qua các giai đoạn tích hợp, ổn định hoặc “củng cố” đầy tổn thất và khó lường vốn đi kèm với các cách tiếp cận khác, ví dụ như các đường phát hành hoặc các nhánh tính năng. Phân phối Liên tục được thiết kế để loại bỏ những hoạt động này.

NỀN TẢNG CỦA KIỂM THỬ TỰ ĐỘNG

Các trường hợp của Google và HP FutureSmart cho thấy, tiến trình tích hợp liên tục phụ thuộc vào kiểm thử tự động toàn diện. Kiểm thử tự động vẫn còn là vấn đề gây tranh cãi trong một số tổ chức, nhưng bạn không thể đạt được thời lượng sản xuất ngắn và sản phẩm lưu hành chất lượng cao mà không có nó. Kiểm thử tự động là một chủ đề quan trọng và phức tạp mà nhiều cuốn sách hay đã nghiên cứu, nhưng dưới đây là một vài điểm quan trọng nhất:

• Kiểm thử tự động hoàn toàn không phải là việc giảm số lượng nhân viên kiểm thử, mà là sự thay đổi vai trò và kỹ năng cần thiết của các nhân viên kiểm thử. Họ cần tập trung vào kiểm thử khám phá và phối hợp với các lập trình viên để sáng tạo và thiết lập các bộ kiểm thử tự động chứ không phải kiểm thử hồi quy thủ công.

• Không thể xây dựng các bộ kiểm thử tự động chất lượng cao nếu các nhân viên kiểm thử không đích thân phối hợp với các lập trình viên (không cần tính đến nhóm hay các cơ chế báo cáo). Việc xây dựng các hệ thống ổn định để kiểm thử tự động đòi hỏi phải có kiến thức tốt về phát triển phần mềm. Ngay từ đầu, nó cũng đòi hỏi phần mềm phải được thiết kế với chế độ kiểm thử tự động, điều không thể có được nếu các lập trình viên không tham gia kiểm thử.

• Việc duy trì kiểm thử tự động có thể trở thành một cơn ác mộng nếu các bộ kiểm thử tự động không được cấu trúc một cách hiệu quả. Một số lượng nhỏ các cuộc kiểm thử chạy nhanh và đáng tin cậy trong phát hiện lỗi còn tốt hơn là một số lượng lớn các cuộc kiểm thử thường xuyên bị gián đoạn và không nhận được sự quan tâm của các lập trình viên.

• Khi thiết kế kiểm thử tự động, phải suy nghĩ về việc vận hành đồng thời nhiều cuộc kiểm thử khác nhau. Điều này cho phép các lập trình viên nhanh chóng nhận được phản hồi và ngăn chặn những tác động xấu, ví dụ như sự phụ thuộc giữa các cuộc kiểm thử.

Các cuộc kiểm thử tự động hỗ trợ cho các loại kiểm thử khác như kiểm thử khám phá, kiểm thử ứng dụng và kiểm thử an ninh. Ý nghĩa của kiểm thử tự động là thẩm định các tính năng gốc và phát hiện những điểm hạn chế để chúng ta không mất thời gian thực hiện kiểm thử (hoặc triển khai) thủ công các phiên bản phần mềm còn chứa những lỗi nghiêm trọng.

• Các cuộc kiểm thử tự động đáng tin cậy đòi hỏi phải có phương pháp quản lý cấu hình và hạ tầng toàn diện. Nó phải hình thành một môi trường kiểm thử ảo tương tự môi trường sản xuất theo yêu cầu, trong khuôn khổ môi trường tích hợp liên tục hoặc trên máy tính chuyên dụng của lập trình viên.

• Chỉ dành thời gian và nỗ lực để kiểm thử các sản phẩm và tính năng đã được thẩm định. Kiểm thử tự động các thử nghiệm là sự lãng phí.

Các ý kiến phản đối tích hợp liên tục chủ yếu đến từ các lập trình viên và nhà quản lý. Việc phá bỏ từng tính năng mới hoặc tái cấu trúc nỗ lực thành các bước nhỏ là điều còn khó khăn hơn việc hoàn thành nó riêng lẻ trên một nhánh, đồng thời cũng mất nhiều thời gian hơn nếu bạn không quen với nguyên tắc làm việc trong các nhóm nhỏ. Như vậy, ban đầu bạn có thể phải mất nhiều thời gian hơn mới có thể tuyên bố rằng các phần việc đã “kết thúc việc phát triển”. Điều này có thể khiến tốc độ phát triển chậm lại và gây ấn tượng rằng tính hiệu quả của nhóm giảm, khiến cho các nhà quản lý giận dữ.

Tuy nhiên, chúng ta nên tối ưu hóa vì tổng thể thời lượng sản xuất – lượng thời gian sử dụng để đưa được phần mềm có giá trị đến với người dùng. Việc tối ưu hóa vì thời gian “kết thúc việc phát triển” chắc chắn sẽ dẫn đến một “địa ngục tích hợp”. Và khi đó, một “chặng cuối” đầy khó khăn và khó lường của tiến trình tích hợp sẽ làm kéo dài các vòng lưu hành sản phẩm, nguyên nhân chính của tình trạng dự án bị kéo dài, phần mềm chất lượng kém, tổng chi phí cao hơn và người dùng không hài lòng.

CÓ ĐÚNG LÀ BẠN ĐANG THỰC HIỆN TÍCH HỢP LIÊN TỤC?

Tích hợp liên tục (CI) là việc khó, và theo kinh nghiệm của chúng tôi, có nhiều nhóm cho rằng họ đang thực hiện điều đó nhưng thực ra thì không phải. Đạt được CI không đơn giản như việc cài đặt và vận hành một công cụ CI; đó là cả một tư duy. Một trong những tài liệu tâm đắc của chúng tôi về CI bàn về cách thực hiện CI mà không có bất kỳ công cụ CI nào, chỉ sử dụng một máy tính cũ, một chú gà cao su và một chiếc chuông (dĩ nhiên là bạn sẽ cần nhiều hơn thế nếu đang làm việc trong một nhóm phát triển lớn, nhưng các nguyên tắc đều giống nhau ở mọi quy mô.)

Để xem có đúng là bạn đang thực hiện CI không, hãy hỏi nhóm của bạn những câu hỏi sau:

• Có phải tất cả các lập trình viên trong nhóm đều kiểm tra trên trục chính (không chỉ kết hợp trục chính với các nhánh của họ hoặc đơn giản là bắt chước) mỗi ngày ít nhất một lần không? Nói cách khác, họ có đang thực hiện phát triển dựa trên trục chính và làm việc trong các nhóm nhỏ hay không?

• Bất kỳ sự thay đổi nào đối với trục chính có giúp khởi động một tiến trình xây dựng, bao gồm việc vận hành một bộ kiểm thử tự động để phát hiện những điểm hồi quy hay không?

• Khi tiến trình xây dựng và kiểm thử thất bại, nhóm có chữa được lỗi trong vòng vài phút, hoặc bằng cách khắc phục điểm đổ vỡ hoặc bằng cách đảo ngược bước thay đổi đã khiến cho tiến trình thất bại?

Nếu câu trả lời cho bất kỳ câu hỏi nào nói trên là “không” thì bạn đang không thực hành tích hợp liên tục. Đặc biệt, đảo ngược những bước thay đổi tồi là một kỹ thuật được thực hiện một cách không đầy đủ. Ví dụ tại Google, bất kỳ ai cũng được trao quyền đảo ngược một bước thay đổi tồi trong kiểm soát phiên bản, ngay cả khi nếu bước đi đó là do người của nhóm khác thực hiện: Họ ưu tiên duy trì hệ thống hoạt động hơn là thực hiện những việc mới.

Dĩ nhiên nếu bạn đang nghiên cứu một ứng dụng lớn và sử dụng nhiều nhánh, thì không dễ để chuyển sang tích hợp liên tục. Trong tình huống này, nên khuyến khích các nhóm chú ý làm việc theo trục chính, bắt đầu với các nhánh bất ổn nhất. Trong một tổ chức lớn, phải mất hàng năm mới có thể giảm từ 100 nhánh xuống còn khoảng 10-15 nhánh.

ĐƯỜNG ỐNG TRIỂN KHAI6

6 Điểm đổ vỡ (Breakage): Tức điểm mà tại đó một người/hệ thống thất bại hoặc mất đi năng lượng.

Xin nhắc lại quy tắc vàng thứ hai của Phân phối Liên tục: Chúng ta phải ưu tiên duy trì hệ thống hoạt động hơn là thực hiện những việc mới. Tích hợp liên tục là một bước quan trọng để hướng đến mục đích này, nhưng về cơ bản, chúng ta sẽ không cảm thấy thoải mái khi đem đến cho người dùng những phần mềm mới chỉ trải qua các cuộc kiểm thử cục bộ.

Nhiệm vụ của đường ống triển khai là đánh giá mọi thay đổi được thực hiện trên hệ thống để phát hiện và bác bỏ những thay đổi có tính rủi ro cao hoặc tác động tiêu cực đến chất lượng, và để cung cấp cho nhóm những phản hồi kịp thời về sự thay đổi của họ để họ có thể giải quyết các vấn đề nhanh chóng và ít tốn kém. Đường ống này đưa tất cả các bước đăng nhập vào kiểm soát phiên bản, tạo ra các gói từ phiên bản đó để có thể triển khai tới bất kỳ môi trường nào, và thực hiện hàng loạt các cuộc kiểm thử đối với phiên bản đó để phát hiện những nhược điểm và thẩm định rằng chức năng quan trọng đó vẫn hoạt động. Nếu gói đó vượt qua được các cuộc kiểm thử này, chúng ta sẽ tự tin triển khai việc xây dựng phần mềm cụ thể đó. Nếu có bất kỳ giai đoạn nào của đường ống triển khai thất bại, thì phiên bản phần mềm đó sẽ không thể tiến xa hơn, và ngay lập tức các kỹ sư phải tập trung tìm ra nguyên nhân của vấn đề và khắc phục nó.

Ngay cả một đường ống triển khai đơn giản nhất, như được thể hiện trong Hình 8-1 (một đường ống triển khai phức tạp hơn được thể hiện trong Hình 8-2), cũng cho phép các thành viên của nhóm thực hiện việc triển khai hoặc kích hoạt các cấu trúc đã trải qua CI trong môi trường kiểm thử khám phá tương tự như môi trường sản xuất hoặc môi trường kiểm thử sự chấp nhận của người dùng. Bạn cần có khả năng cung cấp môi trường kiểm thử và triển khai bất kỳ cấu trúc CI tốt trong các môi trường đó bằng cách sử dụng một tiến trình tự động hoàn toàn. Tiến trình tương tự như vậy cần được áp dụng và triển khai trong quá trình sản xuất.

Đường ống triển khai kết nối tất cả các bước cần thiết để đi từ việc đăng ký đến việc triển khai rồi đến sản xuất (hoặc phân phối tới một kho ứng dụng). Nó cũng kết nối tất cả các bên liên quan vào việc phân phối phần mềm, bao gồm các lập trình viên, nhân viên kiểm thử, kỹ sư phát hành và các chiến dịch – điều giúp nó trở thành một công cụ giao tiếp quan trọng.

35

Hình 8-1. Những thay đổi diễn ra trên một đường ống triển khai đơn giản

Doanh-nghiep-tinh-gon_in-230

Hình 8-2. Một đường ống triển khai phức tạp hơn

ĐƯỜNG ỐNG TRIỂN KHAI FUTURESMART

Đường ống triển khai của nhóm FutureSmart cho phép một nhóm phân tán gồm 400 người tích hợp 100-150 sự thay đổi – khoảng 75.000-100.000 đường mã – vào trục chính trên mã nền gồm 10 triệu đường của họ mỗi ngày. Mỗi ngày, đường ống triển khai tạo ra 10-14 kết cấu chương trình cơ sở tốt ở Mức 1. Tất cả những thay đổi – bao gồm phát triển tính năng và thay đổi quy mô lớn – đều được thực hiện trên trục chính. Các lập trình viên tham chiếu vào trục vài lần mỗi tuần.

Tất cả những thay đổi đối với bất kỳ hệ thống nào – hay đối với các môi trường mà hệ thống đó hoạt động – cần được thực hiện thông qua việc kiểm soát phiên bản và sau đó thúc đẩy qua đường ống triển khai. Điều đó bao gồm không chỉ mã nguồn và mã kiểm thử mà còn cả việc di chuyển cơ sở dữ liệu và các kịch bản triển khai và dự phòng cũng như là những thay đổi đối với máy chủ, kết nối mạng và các cấu hình hạ tầng.

Vì vậy, đường ống triển khai trở thành biên bản ghi chép lại những hoạt động kiểm thử nào đã được thực hiện trên một kết cấu cụ thể và kết quả là gì, những kết cấu nào đã được triển khai tại môi trường nào và khi nào, ai là người chấp thuận thúc đẩy một kết cấu cụ thể và cấu hình của mọi môi trường chính xác là gì, khi nào – thực sự là toàn bộ vòng đời của những thay đổi về mã và hạ tầng khi chúng đi qua các môi trường khác nhau.

Như vậy, điều này có nghĩa là việc thực hiện đường ống triển khai còn có một vài công dụng quan trọng khác ngoài tác dụng loại bỏ những thay đổi mang tính rủi ro cao hoặc có thể gây rắc rối cho hệ thống:

◆ Bạn có thể thu thập những thông tin quan trọng về tiến trình phân phối, như là những thống kê về vòng đời của những thay đổi (sự cân bằng, sự biến thể tiêu chuẩn) và phát hiện những điểm thắt cổ chai trong tiến trình của mình.

◆ Đường ống triển khai cung cấp vô vàn thông tin về các mục đích kiểm toán và sự phục tùng. Các nhà kiểm toán rất yêu thích phương pháp này vì nó cho phép họ theo dõi chính xác mọi chi tiết những mệnh lệnh nào được vận hành trên các khối nào, kết quả là gì, ai phê chuẩn chúng và khi nào…

◆ Đường ống triển khai có thể tạo nền tảng cho một tiến trình nhỏ nhưng toàn diện để quản lý sự thay đổi. Ví dụ, công ty điện thoại National Broadband Network của Úc, một công ty được kiểm soát rất chặt chẽ, đã sử dụng một đường ống triển khai để tự động đưa ra những thẻ quản lý thay đổi khi các thay đổi được thực hiện đối với hạ tầng sản xuất, và để tự động cập nhật CMDB (Cơ sở dữ liệu quản lý cấu hình – Configuration management database) của họ khi cung cấp các hệ thống mới và tiến hành triển khai.

◆ Đường ống triển khai giúp các thành viên trong nhóm có khả năng thực hiện “bấm nút” để triển khai kết cấu mà họ lựa chọn đến môi trường mà họ lựa chọn. Về cơ bản, các công cụ thực hiện đường ống triển khai về cơ bản cho phép đưa ra những quyết định như vậy dựa trên cơ sở môi trường và thúc đẩy tiến độ củng cố kết cấu.

PHÂN PHỐI LIÊN TỤC VÀ KIỂM SOÁT THAY ĐỔI

Nhiều doanh nghiệp có truyền thống sử dụng các ban cố vấn về thay đổi hoặc các hệ thống kiểm soát thay đổi tương tự để giảm rủi ro của những thay đổi đối với môi trường sản xuất. Tuy nhiên, theo Báo cáo Tình hình Phát triển và Vận hành 2014, sau khi điều tra hơn 9.000 cá nhân ở nhiều ngành công nghiệp, phát hiện ra rằng các tiến trình phê duyệt diễn ra ở ngoài các nhóm phát triển không đem lại nhiều lợi ích trong cải thiện khả năng của các dịch vụ (được tính bằng thời gian khôi phục dịch vụ và tỷ lệ của những thay đổi thất bại), trong khi tiêu tốn rất nhiều các nguồn lực đầu vào (được tính bằng thời lượng tạo ra sự thay đổi và tần suất thay đổi). Nghiên cứu này cũng so sánh các tiến trình phê duyệt thay đổi diễn ra ở ngoài tổ chức với các cơ chế bình duyệt của đồng nghiệp như là lập trình đôi6 hoặc sử dụng các yêu cầu kéo7. Phân tích các số liệu thống kê cho thấy khi các nhóm kỹ sư quan tâm đến việc khẳng định chất lượng mã thông qua cơ chế bình duyệt của đồng nghiệp, thời lượng sản xuất và tần suất phát hành đã được cải thiện đáng kể mà không tác động nhiều đến sự ổn định của hệ thống. Các thông tin khác trong Báo cáo ủng hộ việc sử dụng các kỹ thuật được thảo luận trong chương này sẽ được trình bày trong Chương 14.

6 Pair Programming là kiểu lập trình đòi hỏi hai kỹ sư phần mềm cùng tham gia một nỗ lực lập trình chung trên một máy trạm, nghĩa là chỉ có một màn hình, một bàn phím. Mỗi người thực hiện việc mà người kia hiện không làm. Ví dụ, người này gõ các bộ test đơn vị (unit test), người kia nghĩ về các lớp đầu vào (input) sẽ thỏa mãn bộ test đó; hoặc người này viết mã còn người kia quan sát để hướng dẫn hoặc kiểm lỗi. Người ta khuyên rằng hai người nên luân phiên đổi vai trò, khoảng nửa giờ một lần. (ND)

7 Pull request – Một yêu cầu kéo là một phương pháp đệ trình các đóng góp cho một dự án phát triển mở. Điều này thường là cách được ưu tiên đối với việc đệ trình các đóng góp cho một dự án bằng việc sử dụng một hệ thống kiểm soát phiên bản phân tán – DVCS (version control system) như Git. Một yêu cầu kéo xảy ra khi một lập trình viên yêu cầu những thay đổi được đệ trình tới một kho bên ngoài sẽ được xem xét để đưa vào trong một kho chính của dự án. (ND)

Các dữ liệu cho thấy đã đến lúc phải đánh giá lại giá trị mà các tiến trình kiểm soát thay đổi nặng nề đem lại. Cơ chế chuyên gia về thay đổi mã kết hợp với một đường ống triển khai là sự thay thế mạnh mẽ, an toàn, có thể kiểm toán và hiệu quả cao cho cơ chế phê duyệt những thay đổi bên ngoài. Trường hợp nghiên cứu điển hình National Broadband Network (được đề cập ở trên) cho thấy một phương pháp thực thi tiến trình kiểm soát thay đổi nhẹ nhàng phù hợp với những khuôn khổ như là ITIL8 trong một môi trường có kiểm soát. Để hiểu thêm về quản lý sự tuân thủ và rủi ro, xem Chương 12.

8 Information Technology Infrastructure Library – Thư viện cơ sở hạ tầng IT, là bộ tập hợp các thực hành tốt nhất của Quản lý dịch vụ IT (ISMS) tập trung vào việc sắp xếp các dịch vụ IT sao cho phù hợp với yêu cầu kinh doanh. (ND)

Thực hiện Phân phối Liên tục đòi hỏi phải suy nghĩ thận trọng về kiến trúc và tiến trình của các hệ thống và có kế hoạch trước cho một số hoạt động nhất định. Việc lặp lại bất cứ hoạt động thủ công nào cũng cần được coi là một sự lãng phí tiềm tàng và vì vậy phải được đơn giản và tự động hóa. Việc này bao gồm:

Xây dựng

Bạn cần có khả năng tạo ra các gói từ nguồn, có thể triển khai ở bất kỳ môi trường nào, trong một bước riêng rẽ sử dụng một kịch bản được lưu trữ trong kiểm soát phiên bản và có thể được vận hành bởi bất kỳ lập trình viên nào.

Định hình

Bất kỳ ai cũng nên có khả năng tự phục vụ một môi trường kiểm thử (bao gồm cấu hình mạng, cấu hình máy chủ, bất kỳ phần mềm hay ứng dụng cần thiết nào) một cách tự động hoàn toàn. Tiến trình này cũng cần sử dụng thông tin và kịch bản được lưu trữ trong kiểm soát phiên bản. Những thay đổi đối với cấu hình môi trường luôn cần được thực hiện thông qua kiểm soát phiên bản với chi phí thấp và không gây ra sự cố khi loại bỏ các khối và các lệnh tái định hình từ nguồn.

Triển khai

Bất kỳ ai cũng cần có khả năng triển khai các gói ứng dụng trong bất kỳ môi trường nào mà họ có thể tiếp cận sử dụng một tiến trình tự động hoàn toàn vốn dùng những kịch bản được lưu trữ trong kiểm soát phiên bản.

Kiểm thử

Bất kỳ lập trình viên nào cũng cần có khả năng thực hiện những hoạt động kiểm thử tự động hoàn chỉnh trên máy tính của họ cũng như là bất kỳ bộ kiểm thử chọn lọc nào. Các hoạt động kiểm thử cần toàn diện và nhanh chóng và bao gồm cả các cuộc kiểm thử cấp đơn vị và cấp độ chấp nhận.

Chúng tôi yêu cầu phải có hoạt động quản lý cấu hình xuất sắc để tạo cơ sở cho tự động hóa. Đặc biệt, mọi thứ cần thiết để tái tạo hệ thống sản xuất và để xây dựng, kiểm thử và triển khai các dịch vụ của bạn cần phải nằm trong kiểm soát phiên bản. Những thứ này bao gồm không chỉ mã nguồn mà còn cả các kịch bản xây dựng, kiểm thử và triển khai, cấu hình hạ tầng và môi trường, giản đồ cơ sở dữ liệu và kịch bản di chuyển cũng như các tài liệu.

TÁCH RIÊNG TRIỂN KHAI VÀ PHÁT HÀNH

Nguyên tắc quan trọng nhất cho việc thực hiện những hoạt động phát hành rủi ro thấp là: Hãy tách riêng việc triển khai và phát hành. Để hiểu nguyên tắc này, trước tiên chúng ta phải hiểu định nghĩa của những thuật ngữ này.

Triển khai là việc đưa một phiên bản cụ thể của một bộ phận phần mềm vào một môi trường xác định. Quyết định thực hiện một hoạt động triển khai – bao gồm việc đưa vào vận hành – cần phải là một quyết định kỹ thuật thuần túy. Phát hành là tiến trình đưa một tính năng hoặc một bộ tính năng đến với khách hàng. Phát hành cần phải là một quyết định kinh doanh thuần túy.

Hai thuật ngữ này thường được coi là đồng nghĩa, tức là chúng ta dùng hoạt động triển khai làm cơ chế chính để thực hiện lưu hành. Điều này dẫn đến một hậu quả vô cùng tiêu cực: Nó kết hợp một quyết định triển khai mang tính kỹ thuật với một quyết định phát hành mang tính kinh doanh. Đây là nguyên nhân chính của tình trạng chính trị tổ chức xen vào tiến trình triển khai và gây thiệt hại cho cả tổ chức.

Có một số kỹ thuật triển khai phần mềm tới môi trường sản xuất một cách an toàn mà chưa để người dùng tiếp cận các chức năng của nó, nhờ đó chúng ta có thể xác định rằng hệ thống của chúng ta vận hành đúng hay không. Phương pháp đơn giản nhất – và là một trong những phương pháp mạnh mẽ nhất – là triển khai song song (blue- green deployment, đôi khi được gọi là black-red deployments). Mô hình này cần có hai môi trường vận hành riêng rẽ với mã xanh nước biển và xanh lá cây. Vào bất kỳ thời điểm nào thì cũng chỉ một trong số hai môi trường này ở trong trạng thái hoạt động; trong Hình 8-3, đó là môi trường xanh lá cây.

36

Hình 8-3. Triển khai song song (được sự đồng ý của Martin Fowler)

Khi muốn phát hành một phiên bản dịch vụ mới, chúng ta triển khai các gói tính năng mới tới môi trường mà hiện không tồn tại (ví dụ trong trường hợp này là xanh nước biển) và kiểm thử nó khi có thời gian. Lúc này tiến trình phát hành chỉ đơn giản là thay đổi bộ định tuyến để chỉ vào môi trường xanh nước biển; để quay lại, chúng ta chỉ bộ định tuyến trở lại môi trường xanh lá cây. Một biến thể phức tạp hơn sẽ dần hình thành đường đến với môi trường xanh nước biển theo thời gian.

Điều quan trọng đối với các công ty có tiến trình triển khai khó khăn và không thể phát hành trong giờ cao điểm là việc triển khai song song cho phép tiến trình triển khai được hoàn thành một cách an toàn vào giờ làm việc bình thường, nhiều ngày trước khi phát hành theo kế hoạch nếu cần thiết. Lúc đó, bạn có thể thực hiện từ xa một tiến trình phát hành đơn giản hơn nhiều (và quay lại nếu cần thiết) trong các giờ thấp điểm với một nhóm nhân viên nhỏ hơn nhiều.

Một số tổ chức sử dụng các trung tâm dữ liệu chính và dữ liệu hỗ trợ cho các môi trường xanh nước biển và xanh lá cây của mình, qua đó chắc chắn rằng họ có thể thực hiện tiến trình khôi phục thảm họa nóng9 mỗi khi họ triển khai. Tuy nhiên, môi trường xanh nước biển và môi trường xanh lá cây không phân biệt nhau về cơ học. Chúng có thể là môi trường ảo hoặc môi trường lô-gic vận hành trên cùng một cơ sở hạ tầng vật lý (đặc biệt là vì nhìn chung thì môi trường bất hoạt tiêu thụ rất ít các nguồn lực).

9 Hot disaster-recovery: Khi nói đến tốc độ khôi phục dữ liệu, có ba loại khôi phục thảm họa khác nhau: lạnh, ấm và nóng. Khôi phục thảm họa nóng là có một phiên bản hoàn toàn giống trang vận hành của bạn, bao gồm nhân viên, các hệ thống mạng, hệ thống điện và gần như ngay lập tức sao lưu dữ liệu của bạn. Chỉ mất một thời gian rất ngắn để chuyển từ trang chủ đến trang hỗ trợ. (ND)

Triển khai và phát hành cũng có thể được phân biệt theo cấp độ tính năng hoặc thành tố, thay vì cấp độ hệ thống, bằng cách sử dụng một kỹ thuật được gọi là “Ra mắt tối”10. Khi trao đổi về tiến trình phát hành Facebook, Giám đốc Phát hành Chuck Rossi cho biết, tất cả những tính năng chính dự kiến ra mắt trong 6 tháng tiếp theo đều đã được đưa vào vận hành – chỉ là bạn chưa thể nhìn thấy chúng mà thôi. Các lập trình viên bảo vệ các tính năng mới bằng “các nút tính năng”11 để các nhà điều hành có thể chủ động cho phép một số người dùng cụ thể tiếp cận hệ thống trên cơ sở tính năng. Theo cách này, các tính năng được dành trước tiên cho các nhân viên Facebook, sau đó là một số lượng nhỏ người dùng như là một phần của kiểm thử A/B (xem Chương 9). Sau đó, các tính năng đã thẩm định sẽ dần được đưa đến 100% người dùng và được tắt đi khi lượng tải cao hoặc nếu một nhược điểm bị phát hiện. Các nút tính năng cũng có thể được sử dụng để đưa các bộ tính năng khác nhau đến với các nhóm người dùng khác nhau từ một nền tảng đơn.

10 Dark launching là một tiến trình mà phần mềm được phát hành dần dần và vững chắc tới tay người tiêu dùng để nhận được sự phản hồi của người dùng và kiểm thử hiệu năng. (ND)

11 Feature flags hoặc feature toggles − hệ thống để người dùng có thể bật, tắt các tính năng. (ND)

BÍ QUYẾT

Ra mắt tối (Dark Launching) các ứng dụng di động

Thay vì trực tiếp ra mắt các ứng dụng di động mới tại một kho ứng dụng, hãy xây dựng một thương hiệu riêng để triển khai và thẩm định trước khi ra mắt chúng với thương hiệu chính thức của bạn.

KẾT LUẬN

Phân phối Liên tục là một sự thay thế cho các tiến trình phát triển và phát hành theo nhóm lớn. Nó đã được nhiều tổ chức kỹ thuật lớn hoạt động trên nhiều lĩnh vực khác nhau, bao gồm những ngành công nghiệp có tính kiểm soát cao như các dịch vụ tài chính, chấp thuận. Mặc dù xuất phát từ các dịch vụ mạng, mô hình kỹ thuật này đã được áp dụng thành công vào việc phát triển phần mềm gói, chương trình cơ sở và ứng dụng di động. Nó cho phép các tổ chức phản ứng nhanh chóng với nhu cầu thay đổi của khách hàng và tăng chất lượng phần mềm trong khi giảm rủi ro của việc phát hành, đồng thời giảm chi phí phát triển phần mềm.

Văn hóa cũng đóng vai trò quan trọng trong hỗ trợ Phân phối Liên tục. Một nền văn hóa mà sự tương tác giữa các nhóm phát triển, vận hành và an ninh thông tin thường theo hướng “cùng thắng” thì chắc chắn sẽ đem lại hiệu năng cao, ví dụ như văn hóa “sinh lời” của mô hình Westrum (Chương 1).

Khi các tổ chức làm việc để thực hiện Phân phối Liên tục, họ sẽ phải thay đổi cách tiếp cận kiểm soát phiên bản, phát triển phần mềm, kiến trúc, kiểm thử và quản lý cơ sở hạ tầng và cơ sở dữ liệu. Hình 8-4 được tổng kết từ nghiên cứu của chúng tôi về một số tổ chức khác nhau.

Dĩ nhiên là tất cả phần việc này có quan hệ với nhau. Ví dụ, việc xây dựng một bộ kiểm thử tự động bền vững và toàn diện đòi hỏi phải có một kiến trúc cho phép phần mềm được triển khai tại các máy tính cục bộ của lập trình viên, vì vậy đặt ra yêu cầu phải có khả năng thiết lập những môi trường tương tự như môi trường vận hành bằng các kịch bản kiểm soát phiên bản. Tìm ra những gì cần đạt được trước tiên, trong bối cảnh các hệ thống hiện có, có thể là điều phức tạp. Chúng tôi sẽ thảo luận về thay đổi kiến trúc phát triển trong Chương 10.

37

Hình 8-4. Triển khai g-forces (được sự đồng ý của Paul Hammant)

Chúng tôi mạnh mẽ khuyến nghị các bạn bắt đầu bằng quản lý cấu hình toàn diện, tích hợp liên tục và phát triển dựa trên trục chính. Một việc cũng rất quan trọng là xây dựng văn hóa kiểm thử tự động cho các lập trình viên, qua đó đòi hỏi phải cung cấp môi trường kiểm thử theo yêu cầu. Theo kinh nghiệm của chúng tôi, các nỗ lực giải quyết khó khăn trong phát hành hay vận hành, được thảo luận trong Chương 14, không thể tạo ra sự cải tiến có ý nghĩa nếu không có tích hợp liên tục, kiểm thử tự động và cung cấp môi trường tự động.

Câu hỏi dành cho độc giả:

◆ Bạn định nghĩa về việc “hoàn thành” một tính năng được chấp thuận là gì? Ít nhất thì tính năng đó phải được tích hợp vào trục chính và được chứng minh trong một môi trường tương tự môi trường vận hành bằng cách thực hiện các cuộc kiểm thử tự động?

◆ Bạn có đang thực hiện tích hợp liên tục như chúng tôi định nghĩa trong cuốn sách này? Bạn sẽ làm thế nào để bắt đầu việc đó?

◆ Mối quan hệ giữa các lập trình viên, các nhân viên kiểm thử và các nhân viên vận hành IT là phối hợp hay mâu thuẫn? Bạn sẽ thực hiện những bước nào để cải thiện điều đó?

◆ Các hoạt động triển khai sản xuất của bạn có phải là những việc khó khăn, “ồn ào” và gây ra sự tức giận khi đã ngoài giờ làm việc? Bạn thay đổi chúng như thế nào để làm được nhiều việc hơn trong giờ làm việc thông thường?

Doanh Nghiệp Tinh Gọn

Nguồn: Internet

BÌNH LUẬN

Please enter your comment!
Please enter your name here