Hãy thảo luận tại sao các công cụ CI và CI là những thứ hoàn toàn khác nhau.
CI dự định giải quyết nỗi đau nào, ý tưởng đến từ đâu, những xác nhận mới nhất rằng nó hoạt động là gì, làm thế nào để hiểu rằng bạn đã thực hành chứ không chỉ cài đặt Jenkins.
Ý tưởng làm báo cáo về Tích hợp liên tục xuất hiện cách đây một năm, khi tôi đi phỏng vấn và tìm việc làm. Tôi đã nói chuyện với 10-15 công ty, chỉ một trong số họ có thể trả lời rõ ràng CI là gì và giải thích tại sao họ nhận ra rằng mình không có nó. Những người còn lại đang nói những điều vô nghĩa khó hiểu về Jenkins :) Chà, chúng ta có Jenkins, nó xây dựng được, CI! Trong báo cáo, tôi sẽ cố gắng giải thích Tích hợp liên tục thực sự là gì và tại sao Jenkins cũng như các công cụ tương tự có mối quan hệ rất yếu với điều này.
Vậy bạn thường nghĩ đến điều gì khi nghe từ CI? Hầu hết mọi người sẽ nghĩ đến Jenkins, Gitlab CI, Travis, v.v.
Ngay cả khi chúng tôi google nó, nó sẽ cung cấp cho chúng tôi những công cụ này.
Nếu bạn đã quen với việc hỏi thì ngay sau khi liệt kê các công cụ, họ sẽ cho bạn biết CI là khi bạn xây dựng và chạy thử nghiệm trong Pull Yêu cầu cho một cam kết.
Tích hợp liên tục không phải là về các công cụ, không phải về các tập hợp với các bài kiểm tra trong nhánh! Tích hợp liên tục là thực hành tích hợp mã mới rất thường xuyên và để sử dụng nó, không cần thiết phải vượt qua Jenkins, GitLab, v.v.
Trước khi tìm hiểu một CI chính thức trông như thế nào, trước tiên chúng ta hãy đi sâu vào bối cảnh của những người đã nghĩ ra nó và cảm nhận những khó khăn mà họ đang cố gắng giải quyết.
Và họ đã giải quyết được nỗi đau khi làm việc cùng nhau như một đội!
Hãy xem ví dụ về những khó khăn mà các nhà phát triển gặp phải khi phát triển theo nhóm. Ở đây chúng tôi có một dự án, một nhánh chính trong git và hai nhà phát triển.
Và họ đi làm như mọi người đã quen từ lâu. Chúng tôi đã thực hiện một nhiệm vụ trong sơ đồ lớn của mọi thứ, tạo một nhánh tính năng và viết mã.
Một người đã hoàn thành tính năng này nhanh hơn và hợp nhất nó vào tính năng chính.
Cái thứ hai cần thêm thời gian, nó hợp nhất sau đó và kết thúc bằng xung đột. Giờ đây, thay vì viết ra các tính năng mà doanh nghiệp cần, nhà phát triển dành thời gian và sức lực của mình để giải quyết các xung đột.
Việc kết hợp tính năng của bạn với một chủ chung càng khó thì chúng tôi càng dành nhiều thời gian cho nó. Và tôi đã chỉ ra điều này bằng một ví dụ khá đơn giản. Đây là một ví dụ khi chỉ có 2 nhà phát triển. Hãy tưởng tượng nếu 10 hoặc 15 hoặc 100 người trong một công ty viết vào một kho lưu trữ. Bạn sẽ phát điên để giải quyết tất cả những xung đột này.
Có một trường hợp hơi khác một chút. Chúng tôi có một bậc thầy và một số nhà phát triển đang làm gì đó.
Họ đã tạo ra một cành cây.
Một người chết, mọi chuyện đều ổn, anh ấy đã hoàn thành nhiệm vụ.
Trong khi đó, nhà phát triển thứ hai đã bàn giao nhiệm vụ của mình. Giả sử anh ấy đã gửi nó để xem xét. Nhiều công ty có một hoạt động gọi là đánh giá. Một mặt, cách thực hành này tốt và hữu ích, mặt khác, nó làm chúng ta chậm lại về nhiều mặt. Chúng ta sẽ không đi sâu vào vấn đề đó nhưng đây là một ví dụ tuyệt vời về hậu quả mà một câu chuyện đánh giá tồi có thể dẫn đến. Bạn đã gửi yêu cầu kéo để xem xét. Nhà phát triển không còn gì để làm. Anh ấy bắt đầu làm gì? Anh ấy bắt đầu đảm nhận các nhiệm vụ khác.
Trong thời gian này, nhà phát triển thứ hai đã làm một việc khác.
Người đầu tiên đã hoàn thành nhiệm vụ thứ ba.
Và sau một thời gian dài, đánh giá của anh ấy đã được kiểm tra và anh ấy đang cố gắng đạt được thỏa thuận. Vì vậy những gì đang xảy ra? Nó nắm bắt được một số lượng lớn các xung đột. Tại sao? Bởi vì trong khi yêu cầu kéo của anh ấy bị treo trong phần đánh giá, rất nhiều thứ đã thay đổi trong mã.
Ngoài câu chuyện có mâu thuẫn, còn có câu chuyện có tính giao tiếp. Trong khi chuỗi của bạn đang chờ xem xét, trong khi nó đang chờ đợi điều gì đó, trong khi bạn đang làm việc trên một tính năng trong một thời gian dài, bạn sẽ ngừng theo dõi những gì khác đang thay đổi trong cơ sở mã dịch vụ của mình. Có lẽ điều bạn đang cố gắng giải quyết bây giờ đã được giải quyết ngày hôm qua và bạn có thể áp dụng một số phương pháp và sử dụng lại nó. Nhưng bạn sẽ không thấy điều này vì bạn luôn làm việc với một nhánh lỗi thời. Và nhánh lỗi thời này luôn dẫn đến việc bạn phải giải quyết xung đột hợp nhất.
Hóa ra là nếu chúng tôi làm việc theo nhóm, tức là không phải một người lục lọi trong kho lưu trữ mà là 5-10 người, thì chúng tôi không thêm mã của mình vào mã gốc càng lâu thì chúng tôi càng đau khổ vì cuối cùng chúng tôi cần một cái gì đó sau đó hợp nhất nó. Và chúng ta càng có nhiều xung đột và chúng ta làm việc với phiên bản cũ hơn thì chúng ta càng gặp nhiều vấn đề hơn.
Làm việc gì đó cùng nhau thật là đau đớn! Chúng tôi luôn cản đường nhau.
Vấn đề này đã được chú ý hơn 20 năm trước. Tôi tìm thấy đề cập đầu tiên về việc thực hành Tích hợp liên tục trong Lập trình cực đoan.
Lập trình cực đoan là khung linh hoạt đầu tiên. Trang này xuất hiện vào năm 96. Và ý tưởng là sử dụng một số phương pháp lập trình, lập kế hoạch và những thứ khác để quá trình phát triển trở nên linh hoạt nhất có thể, nhờ đó chúng tôi có thể nhanh chóng đáp ứng mọi thay đổi hoặc yêu cầu từ khách hàng. Và họ bắt đầu phải đối mặt với điều này 24 năm trước, rằng nếu bạn làm điều gì đó trong thời gian rất dài và bên lề, thì bạn sẽ dành nhiều thời gian hơn cho việc đó vì bạn có mâu thuẫn.
Bây giờ chúng ta sẽ phân tích riêng từng cụm từ “Tích hợp liên tục”. Nếu chúng ta dịch nó trực tiếp, chúng ta sẽ có được sự tích hợp liên tục. Nhưng nó liên tục đến mức nào thì không rõ ràng lắm; nó rất gián đoạn. Nhưng nó tích hợp đến mức nào cũng không rõ ràng lắm.
Và đó là lý do tại sao bây giờ tôi sẽ đưa ra cho bạn những trích dẫn từ Extreme Programming. Và chúng tôi sẽ phân tích cả hai từ một cách riêng biệt.
Tích hợp - Như tôi đã nói, chúng tôi cố gắng đảm bảo rằng mọi kỹ sư đều làm việc với phiên bản mã mới nhất, để anh ấy cố gắng thêm mã của mình thường xuyên nhất có thể vào một nhánh chung để đây là những nhánh nhỏ. Vì nếu chúng lớn thì chúng ta dễ bị mắc kẹt trong các xung đột hợp nhất trong cả tuần. Điều này đặc biệt đúng nếu chúng ta có một chu kỳ phát triển dài chẳng hạn như thác nước, nơi mà nhà phát triển đã mất cả tháng để cắt bỏ một số tính năng lớn. Và anh ấy sẽ bị mắc kẹt ở giai đoạn hội nhập trong một thời gian rất dài.
Tích hợp là khi chúng ta lấy nhánh của mình và tích hợp nó với bản gốc, chúng ta hợp nhất nó. Có một lựa chọn tối ưu khi chúng tôi là nhà phát triển transbase, nơi chúng tôi cố gắng đảm bảo rằng chúng tôi viết thư ngay cho chủ mà không cần thêm bất kỳ chi nhánh nào.
Nói chung, tích hợp có nghĩa là lấy mã của bạn và kéo nó vào bản gốc.
Ở đây chữ “liên tục” có nghĩa là gì, cái gì được gọi là sự liên tục? Thực tiễn ngụ ý rằng nhà phát triển cố gắng tích hợp mã của mình càng nhanh càng tốt. Đây là mục tiêu của anh ấy khi thực hiện bất kỳ nhiệm vụ nào - đưa mã của anh ấy thành chủ càng nhanh càng tốt. Trong một thế giới lý tưởng, các nhà phát triển sẽ làm việc này vài giờ một lần. Tức là bạn lấy một bài toán nhỏ và hợp nhất nó thành bài toán gốc. Mọi thứ đều tuyệt vời. Đây là những gì bạn phấn đấu cho. Và việc này phải được thực hiện liên tục. Ngay khi bạn làm điều gì đó, bạn lập tức đưa nó vào chủ.
Và nhà phát triển tạo ra thứ gì đó phải chịu trách nhiệm về những gì mình đã làm để khiến nó hoạt động và không vi phạm bất cứ điều gì. Đây là nơi câu chuyện thử nghiệm thường xuất hiện. Chúng tôi muốn chạy một số thử nghiệm trên cam kết của mình, khi hợp nhất để đảm bảo rằng nó hoạt động. Và đây là lúc Jenkins có thể giúp bạn.
Nhưng với những câu chuyện: hãy thực hiện những thay đổi nhỏ, hãy để những nhiệm vụ nhỏ, hãy đặt ra một vấn đề và ngay lập tức cố gắng bằng cách nào đó nhúng nó vào bản gốc - không có Jenkins nào giúp đỡ ở đây. Bởi vì Jenkins sẽ chỉ giúp bạn chạy thử nghiệm mà thôi.
Bạn có thể làm mà không cần họ. Điều này sẽ không làm tổn thương bạn chút nào. Bởi vì mục tiêu của việc luyện tập là đo lường thường xuyên nhất có thể để không lãng phí nhiều thời gian cho bất kỳ xung đột nào trong tương lai.
Hãy tưởng tượng rằng vì lý do nào đó mà chúng ta đang ở năm 2020 không có Internet. Và chúng tôi làm việc tại địa phương. Chúng tôi không có Jenkins. Điều này ổn. Bạn vẫn có thể tiếp tục và tạo một chi nhánh địa phương. Bạn đã viết một số mã trong đó. Chúng tôi đã hoàn thành nhiệm vụ trong 3-4 giờ. Chúng tôi chuyển sang master, thực hiện thao tác kéo git và sáp nhập chi nhánh của mình vào đó. Sẵn sàng. Nếu bạn làm điều này thường xuyên thì xin chúc mừng, bạn có Tích hợp liên tục!
Có bằng chứng nào trong thế giới hiện đại cho thấy nó đáng để bạn tiêu tốn năng lượng? Vì nói chung là khó. Nếu bạn cố gắng làm việc như thế này, bạn sẽ hiểu rằng bây giờ một số kế hoạch sẽ bị ảnh hưởng, bạn sẽ phải dành nhiều thời gian hơn để phân tích các nhiệm vụ. Bởi vì nếu bạn làm vậy..., thì bạn sẽ không thể nhanh chóng đạt được thỏa thuận và do đó, sẽ gặp rắc rối. Bạn sẽ không còn thực hành nữa.
Và nó sẽ đắt tiền. Sẽ không thể hoạt động ngay từ ngày mai bằng cách sử dụng Tích hợp liên tục. Các bạn sẽ phải mất rất nhiều thời gian để làm quen, sẽ phải mất rất nhiều thời gian để làm quen với việc phân rã các công việc, sẽ phải mất rất nhiều thời gian để làm quen với việc làm lại bài tập ôn tập, nếu có . Bởi vì mục tiêu của chúng ta là làm cho nó tan chảy ngày hôm nay. Và nếu bạn thực hiện đánh giá trong vòng ba ngày thì bạn sẽ gặp vấn đề và Tích hợp liên tục không hiệu quả với bạn.
Nhưng hiện tại chúng ta có bằng chứng liên quan nào cho thấy rằng đầu tư vào hoạt động này là hợp lý không?
Điều đầu tiên tôi nghĩ đến là State of DevOps. Đây là một nghiên cứu mà các chàng trai đã thực hiện trong 7 năm. Bây giờ họ làm việc đó với tư cách là một tổ chức độc lập, nhưng dưới sự quản lý của Google.
Và nghiên cứu năm 2018 của họ cho thấy mối tương quan giữa các công ty cố gắng sử dụng các chi nhánh có thời gian tồn tại ngắn, tích hợp nhanh chóng, tích hợp thường xuyên và có các chỉ số hiệu suất CNTT tốt hơn.
Những chỉ số này là gì? Đây là 4 số liệu mà họ lấy từ tất cả các công ty trong bảng câu hỏi của mình: tần suất triển khai, thời gian thực hiện thay đổi, thời gian khôi phục dịch vụ, tỷ lệ thất bại khi thay đổi.
Và trước hết, có mối tương quan này, chúng tôi biết rằng các công ty đo lường thường xuyên có số liệu tốt hơn nhiều. Và họ chia các công ty thành nhiều loại: đây là những công ty chậm sản xuất thứ gì đó chậm, hiệu suất trung bình, hiệu suất cao và ưu tú. Tinh hoa là Netflix, Amazon siêu nhanh, làm gì cũng nhanh, đẹp và hiệu quả.
Câu chuyện thứ hai, xảy ra cách đây chỉ một tháng. Technology Radar có một bài viết rất hay về Gitflow. Gitflow khác với tất cả những thứ khác ở chỗ các nhánh của nó tồn tại lâu dài. Có những nhánh phát hành tồn tại trong thời gian dài và các nhánh đặc trưng cũng tồn tại trong thời gian dài. Hoạt động này tại Technology Radar đã chuyển sang GIỮ. Tại sao? Bởi con người phải đối mặt với nỗi đau hội nhập.
Nếu nhánh của bạn tồn tại trong một thời gian rất dài, nó sẽ bị mắc kẹt, mục nát và chúng ta bắt đầu dành nhiều thời gian hơn để cố gắng thực hiện một số thay đổi cho nó.
Và gần đây tác giả của Gitflow đã nói rằng nếu mục tiêu của bạn là Tích hợp liên tục, nếu mục tiêu của bạn là muốn triển khai thường xuyên nhất có thể thì Gitflow là một ý tưởng tồi. Anh ấy đã nói thêm riêng vào bài viết rằng nếu bạn có một phần phụ trợ để bạn có thể phấn đấu đạt được điều này, thì Gitflow là không cần thiết đối với bạn, vì Gitflow sẽ làm bạn chậm lại, Gitflow sẽ tạo ra vấn đề cho bạn khi tích hợp.
Điều này không có nghĩa là Gitflow xấu và không nên sử dụng. Nó dành cho những dịp khác. Ví dụ: khi bạn cần hỗ trợ một số phiên bản của dịch vụ hoặc ứng dụng, tức là bạn cần hỗ trợ trong một thời gian dài.
Nhưng nếu bạn nói chuyện với những người hỗ trợ các dịch vụ như vậy, bạn sẽ nghe thấy rất nhiều đau đớn về thực tế là phiên bản này là 3.2, cách đây 4 tháng, nhưng bản sửa lỗi này không được đưa vào và bây giờ, để tạo ra nó, bạn cần phải thực hiện một loạt các thay đổi. Và bây giờ họ lại mắc kẹt, và bây giờ họ đã loay hoay suốt một tuần để cố gắng triển khai một số tính năng mới.
Như Alexander Kovalev đã lưu ý một cách chính xác trong cuộc trò chuyện, mối tương quan không giống như quan hệ nhân quả. Điều này là đúng. Nghĩa là, không có mối liên hệ trực tiếp nào rằng nếu bạn có Tích hợp liên tục thì tất cả các số liệu sẽ tuyệt vời. Nhưng có một mối tương quan tích cực rằng nếu một người là một thì rất có thể người kia cũng vậy. Không phải là sự thật, nhưng rất có thể. Nó chỉ là một mối tương quan.
Có vẻ như chúng ta đang làm điều gì đó, có vẻ như chúng ta đang hợp nhất, nhưng làm sao chúng ta có thể hiểu rằng chúng ta vẫn có Tích hợp liên tục, rằng chúng ta đang hợp nhất khá thường xuyên?
Jez Humble là tác giả của Sổ tay, Tăng tốc, trang web Phân phối liên tục và cuốn sách Phân phối liên tục. Anh ấy đưa ra bài kiểm tra này:
- Mã của kỹ sư được gửi đến chủ mỗi ngày.
- Đối với mỗi cam kết, bạn chạy thử nghiệm đơn vị.
- Bản dựng trong bản gốc bị đổ, nó được sửa trong khoảng 10 phút.
Anh ấy gợi ý nên sử dụng một bài kiểm tra như thế này để đảm bảo bạn đã thực hành đủ.
Tôi thấy điều sau hơi gây tranh cãi. Tức là nếu bạn khắc phục được trong 10 phút thì bạn đã có Tích hợp liên tục, theo tôi thì nghe hơi lạ nhưng cũng có lý. Tại sao? Bởi vì nếu bạn đóng băng thường xuyên, điều đó có nghĩa là những thay đổi của bạn là nhỏ. Nếu một thay đổi nhỏ có nghĩa là bản dựng chính của bạn bị hỏng thì bạn có thể nhanh chóng tìm thấy một ví dụ vì thay đổi đó rất nhỏ. Ở đây bạn đã có một sự hợp nhất nhỏ, 20-30 dòng trong đó đã thay đổi. Và theo đó, bạn có thể nhanh chóng hiểu lý do là gì, vì những thay đổi rất nhỏ, bạn có một khu vực rất nhỏ để tìm kiếm vấn đề.
Và ngay cả khi sản phẩm của chúng tôi không thành công sau khi phát hành, thì nếu chúng tôi thực hành Tích hợp liên tục, chúng tôi sẽ hành động dễ dàng hơn nhiều vì những thay đổi là rất nhỏ. Có, điều này sẽ ảnh hưởng đến việc lập kế hoạch. Điều này sẽ đau. Và, có lẽ, điều khó khăn nhất trong cách thực hành này là làm quen với việc chia nhỏ các nhiệm vụ, tức là làm thế nào để bạn có thể lấy một việc gì đó và thực hiện trong vài giờ, đồng thời vượt qua bài đánh giá, nếu bạn có một. Đánh giá là một nỗi đau riêng biệt.
Kiểm tra đơn vị chỉ là một trợ lý giúp bạn hiểu liệu quá trình tích hợp của bạn có thành công hay không và liệu có gì bị hỏng hay không. Theo tôi, điều này cũng không hoàn toàn bắt buộc, vì đây không phải là quan điểm thực tiễn.
Đây là phần giới thiệu ngắn gọn về Tích hợp liên tục. Đó là tất cả những gì có trong thực hành này. Tôi đã sẵn sàng cho các câu hỏi.
Tôi sẽ chỉ tóm tắt ngắn gọn lại:
- Tích hợp liên tục không phải là Jenkins, không phải là Gitlab.
- Đây không phải là một công cụ, mà là một cách thực hành để chúng tôi hợp nhất mã của mình vào mã gốc thường xuyên nhất có thể.
- Chúng tôi làm điều này để tránh nỗi đau to lớn phát sinh khi hợp nhất trong tương lai, nghĩa là hiện tại chúng tôi trải qua một chút nỗi đau để không phải trải qua nhiều hơn trong tương lai. Đó là toàn bộ vấn đề.
- Bên cạnh có giao tiếp thông qua mã, nhưng tôi rất hiếm khi thấy điều này, nhưng đây cũng là mục đích của nó.
câu hỏi
Phải làm gì với các nhiệm vụ không bị phân hủy?
Phân hủy. Vấn đề là gì? Bạn có thể đưa ra một ví dụ rằng có một nhiệm vụ và nó không bị phân tách?
Có những nhiệm vụ không thể tách rời khỏi từ “hoàn toàn”, chẳng hạn như những nhiệm vụ đòi hỏi chuyên môn rất sâu và thực sự có thể giải quyết trong suốt một tháng để đạt được một số kết quả dễ hiểu.
Nếu tôi hiểu chính xác bạn, thì có một số nhiệm vụ lớn và phức tạp, kết quả của nó sẽ chỉ hiển thị sau một tháng?
Vâng đúng vậy. Có, có thể đánh giá kết quả không sớm hơn một tháng.
Khỏe. Nói chung đây không phải là một vấn đề. Tại sao? Bởi vì trong trường hợp này, khi nói về cành cây, chúng ta không nói về cành cây có một đặc điểm nào đó. Các tính năng có thể lớn và phức tạp. Chúng có thể ảnh hưởng đến một số lượng lớn các thành phần. Và có lẽ chúng ta không thể thực hiện chúng hoàn toàn trong một nhánh. Điều này ổn. Chúng ta chỉ cần chia nhỏ câu chuyện này. Nếu một tính năng chưa hoàn toàn sẵn sàng, điều này không có nghĩa là một số đoạn mã của nó không thể hợp nhất được. Ví dụ: bạn đã thêm quá trình di chuyển và có một số giai đoạn bên trong tính năng này. Giả sử bạn có một giai đoạn - thực hiện di chuyển, thêm phương thức mới. Và bạn đã có thể đo lường những điều này hàng ngày.
Khỏe. Vấn đề là gì?
Giết những thứ nhỏ nhặt mỗi ngày để làm gì?
Vâng.
Nếu họ làm vỡ thứ gì đó, bạn sẽ thấy ngay. Bạn có một mảnh nhỏ bị gãy cái gì đó, bạn sẽ dễ dàng sửa chữa hơn. Vấn đề là việc hợp nhất một phần nhỏ bây giờ dễ dàng hơn nhiều so với việc hợp nhất một phần lớn trong vài tuần. Và điểm thứ ba là các kỹ sư khác sẽ làm việc với phiên bản mã hiện tại. Họ sẽ thấy rằng một số di chuyển đã được thêm vào đây và sau đó một số phương pháp đã xuất hiện mà họ cũng có thể muốn sử dụng. Mọi người sẽ thấy những gì đang xảy ra trong mã của bạn. Chính vì ba điều này mà sự thực hành được thực hiện.
Cảm ơn bạn, vấn đề đã được đóng lại!
(Oleg Soroka) Tôi có thể thêm vào được không? Bạn nói đúng lắm, tôi chỉ muốn thêm một câu thôi.
So.
Với Tích hợp liên tục, mã được hợp nhất thành một nhánh chung không phải khi tính năng này hoàn toàn sẵn sàng mà khi quá trình xây dựng ngừng hỏng. Và bạn có thể yên tâm cam kết làm chủ bao nhiêu lần trong ngày tùy thích. Khía cạnh thứ hai là nếu vì lý do nào đó mà bạn không thể chia nhiệm vụ hàng tháng thành các nhiệm vụ trong ít nhất ba ngày, tôi im lặng khoảng ba giờ, thì bạn đang gặp vấn đề lớn. Và việc bạn không có Tích hợp liên tục là vấn đề nhỏ nhất trong số những vấn đề này. Điều này có nghĩa là bạn gặp vấn đề với kiến trúc và thực hành kỹ thuật bằng không. Bởi vì ngay cả khi đây là nghiên cứu thì trong mọi trường hợp, nó phải được xây dựng dưới dạng giả thuyết hoặc một chu trình.
Chúng ta đã nói về 4 thước đo giúp phân biệt các công ty thành công và những công ty tụt hậu. Chúng ta vẫn phải sống để nhìn thấy 4 số liệu này. Nếu nhiệm vụ trung bình của bạn mất một tháng để hoàn thành thì trước tiên tôi sẽ tập trung vào số liệu này. Đầu tiên tôi sẽ giảm xuống còn 3 ngày. Và sau đó tôi bắt đầu nghĩ về Liên tục.
Tôi có hiểu chính xác rằng bạn nghĩ rằng nói chung không có ích gì khi đầu tư vào thực hành kỹ thuật nếu bất kỳ nhiệm vụ nào phải mất một tháng để hoàn thành?
Bạn có Tích hợp liên tục. Và có một chủ đề như vậy mà trong 10 phút bạn có thể sửa một bản sửa lỗi hoặc khôi phục lại. Hãy tưởng tượng bạn lăn nó ra. Hơn nữa, bạn thậm chí còn triển khai liên tục, bạn triển khai nó để sản xuất và chỉ sau đó mới nhận thấy có điều gì đó không ổn. Và bạn cần khôi phục nó lại, nhưng bạn đã di chuyển cơ sở dữ liệu của mình. Bạn đã có lược đồ cơ sở dữ liệu của phiên bản tiếp theo, hơn nữa, bạn cũng có một số loại bản sao lưu và dữ liệu cũng được ghi vào đó.
Và bạn có lựa chọn thay thế nào? Nếu bạn khôi phục mã thì nó sẽ không thể hoạt động với cơ sở dữ liệu cập nhật này nữa.
Căn cứ chỉ di chuyển về phía trước, vâng.
Những người có trình độ kỹ thuật kém rất có thể cũng chưa đọc cuốn sách dày về.... Phải làm gì với bản sao lưu? Nếu bạn khôi phục từ bản sao lưu, điều đó có nghĩa là bạn sẽ mất dữ liệu đã tích lũy trong thời điểm đó. Ví dụ: chúng tôi đã làm việc trong ba giờ với phiên bản mới của cơ sở dữ liệu, người dùng đã đăng ký ở đó. Bạn từ chối bản sao lưu cũ vì chương trình không hoạt động với phiên bản mới nên bạn đã mất những người dùng này. Và họ không hài lòng, họ thề.
Để nắm vững đầy đủ các phương pháp thực hành hỗ trợ Tích hợp liên tục và Phân phối liên tục, việc chỉ học cách viết là chưa đủ.... Thứ nhất, có thể có rất nhiều, nó sẽ không thực tế. Ngoài ra còn có một loạt các hoạt động khác như Khoa học. Có một cách làm như vậy, GitHub đã phổ biến nó một thời. Đây là khi bạn có cả mã cũ và mã mới chạy cùng lúc. Đây là khi bạn tạo một tính năng chưa hoàn thiện nhưng nó có thể trả về một số giá trị: dưới dạng hàm hoặc API còn lại. Bạn thực thi cả mã mới và mã cũ và so sánh sự khác biệt giữa chúng. Và nếu có sự khác biệt thì bạn ghi lại sự kiện này. Bằng cách này, bạn biết rằng bạn có một tính năng mới sẵn sàng triển khai trên tính năng cũ nếu bạn không có sự khác biệt giữa hai tính năng này trong một thời gian nhất định.
Có hàng trăm cách thực hành như vậy. Tôi khuyên bạn nên bắt đầu với việc phát triển transbase. Cô ấy không hoàn toàn 100% về Tích hợp liên tục, nhưng cách thực hành đều giống nhau, người này không thể sống tốt nếu thiếu người kia.
Bạn đã đưa ra ví dụ về việc phát triển transbase để bạn có thể xem các phương pháp thực hành hay bạn đề xuất mọi người bắt đầu sử dụng tính năng gỡ lỗi transbase?
Hãy xem vì họ sẽ không thể sử dụng nó. Để sử dụng chúng, bạn cần phải đọc rất nhiều. Và khi một người hỏi: “Phải làm gì với một tính năng mất một tháng, điều đó có nghĩa là anh ta chưa đọc về quá trình phát triển transbase.” Tôi chưa muốn giới thiệu nó. Tôi khuyên bạn chỉ nên tập trung vào chủ đề làm thế nào để chia nhỏ các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn một cách chính xác về mặt kiến trúc. Đây là bản chất của sự phân hủy.
Phân hủy là một trong những công cụ của kiến trúc sư. Đầu tiên chúng ta thực hiện phân tích, sau đó phân rã, tổng hợp, rồi tích hợp. Và đây là cách mọi thứ diễn ra với chúng tôi. Và chúng ta vẫn cần phát triển đến Tích hợp liên tục thông qua quá trình phân rã. Các câu hỏi nảy sinh ở giai đoạn đầu tiên và chúng ta đang nói về giai đoạn thứ tư, tức là chúng ta thực hiện tích hợp càng thường xuyên thì càng tốt. Vẫn còn quá sớm để làm điều này; tốt nhất là bạn nên cắt bỏ khối nguyên khối của mình trước.
Bạn cần vẽ một số mũi tên và hình vuông trên một số sơ đồ. Bạn không thể nói rằng bây giờ tôi sẽ hiển thị sơ đồ kiến trúc của một ứng dụng mới và hiển thị một hình vuông, bên trong có một nút màu xanh lá cây dành cho ứng dụng. Trong mọi trường hợp, sẽ có nhiều hình vuông và mũi tên hơn. Mỗi sơ đồ tôi thấy đều có nhiều hơn một. Và sự phân rã, thậm chí ở cấp độ biểu diễn đồ họa, đã diễn ra. Vì vậy, các hình vuông có thể được thực hiện độc lập. Nếu không thì tôi có một câu hỏi lớn dành cho kiến trúc sư.
Có một câu hỏi từ cuộc trò chuyện: “Nếu việc xem xét là bắt buộc và mất nhiều thời gian, có thể là một ngày hoặc hơn?”
Bạn có vấn đề với việc thực hành. Việc xem xét không nên kéo dài một ngày hoặc hơn. Đây là câu chuyện tương tự như câu hỏi trước, chỉ nhẹ nhàng hơn một chút. Nếu quá trình đánh giá diễn ra trong một ngày thì rất có thể quá trình đánh giá này đang diễn ra một sự thay đổi rất lớn nào đó. Điều này có nghĩa là nó cần phải được làm nhỏ hơn. Trong quá trình phát triển transbase, điều mà Oleg khuyến nghị, có một câu chuyện được gọi là đánh giá liên tục. Ý tưởng của cô ấy là chúng tôi cố tình thực hiện một yêu cầu kéo nhỏ như vậy, bởi vì chúng tôi cố gắng hợp nhất liên tục và từng chút một. Và do đó, yêu cầu kéo sẽ thay đổi một phần trừu tượng hoặc 10 dòng. Nhờ đánh giá này, chúng tôi mất một vài phút.
Nếu quá trình xem xét mất một ngày hoặc hơn thì có điều gì đó không ổn. Thứ nhất, bạn có thể gặp một số vấn đề với kiến trúc. Hoặc đây là một đoạn mã lớn, 1 dòng chẳng hạn. Hoặc kiến trúc của bạn phức tạp đến mức một người không thể hiểu được. Đây là một vấn đề hơi nghiêng về một bên, nhưng nó cũng sẽ phải được giải quyết. Có lẽ không cần phải review gì cả. Chúng ta cũng cần suy nghĩ về điều này. Đánh giá là điều làm bạn chậm lại. Nói chung nó có những ưu điểm, nhưng bạn cần hiểu lý do tại sao bạn lại làm việc đó. Đây là cách để bạn truyền tải thông tin nhanh chóng, đây là cách để bạn đặt ra một số tiêu chuẩn trong nội bộ hay sao? Tại sao bạn cần điều này? Bởi vì việc xem xét cần phải được thực hiện rất nhanh chóng hoặc bị hủy bỏ hoàn toàn. Nó giống như sự phát triển của transbase - câu chuyện rất hay nhưng chỉ dành cho những chàng trai trưởng thành.
Về 4 chỉ số, tôi vẫn khuyên bạn nên xóa chúng để hiểu điều này dẫn đến điều gì. Nhìn vào những con số, nhìn vào bức tranh, mọi thứ tệ đến mức nào.
(Dmitry) Tôi sẵn sàng tham gia thảo luận về vấn đề này với bạn. Những con số và thước đo đều tuyệt vời, những phương pháp thực hành cũng tuyệt vời. Nhưng bạn cần phải hiểu liệu doanh nghiệp có cần nó hay không. Có những doanh nghiệp không cần tốc độ thay đổi đó. Tôi biết những công ty không thể thực hiện thay đổi cứ sau 15 phút. Và không phải vì họ quá tệ. Đây là một vòng đời như vậy. Và để làm được tính năng rẽ nhánh, tính năng chuyển đổi thì bạn cần có kiến thức sâu rộng.
Nó phức tạp lắm. Nếu bạn muốn đọc câu chuyện về tính năng chuyển đổi chi tiết hơn, tôi khuyên bạn nên đọc nó . Và có một bài viết tuyệt vời của Martin Fowler về các tính năng chuyển đổi: có những loại nào, vòng đời, v.v. Tính năng chuyển đổi rất phức tạp.
Và bạn vẫn chưa trả lời được câu hỏi: “Có cần Jenkins hay không?”
Jenkins thực sự không cần thiết trong mọi trường hợp. Nghiêm túc mà nói, các công cụ: Jenkins, Gitlab sẽ mang đến cho bạn sự tiện lợi. Bạn sẽ thấy rằng lắp ráp được lắp ráp hoặc không lắp ráp. Họ có thể giúp bạn, nhưng họ sẽ không cho bạn thực hành. Họ chỉ có thể cho bạn một vòng tròn - Ok, không Ok. Và sau đó, nếu bạn cũng viết bài kiểm tra, vì nếu không có bài kiểm tra thì gần như vô nghĩa. Vì vậy, nó cần thiết vì nó tiện lợi hơn nhưng nhìn chung bạn có thể sống mà không cần nó, bạn sẽ không mất nhiều.
Nghĩa là, nếu bạn có thực hành, điều đó có nghĩa là bạn không cần nó?
Đúng rồi. Tôi khuyên bạn nên thử bài kiểm tra Jez Humble. Ở đó tôi có một thái độ mâu thuẫn đối với điểm cuối cùng. Nhưng nói chung, nếu bạn có ba thứ, bạn hợp nhất liên tục, bạn chạy thử nghiệm các cam kết trong bản gốc, bạn nhanh chóng sửa bản dựng trong bản gốc, thì có lẽ bạn không cần bất cứ thứ gì khác.
Trong khi chờ đợi câu hỏi từ những người tham gia, tôi có một câu hỏi. Chúng ta chỉ đang nói về mã sản phẩm. Bạn đã sử dụng nó cho mã cơ sở hạ tầng chưa? Nó có giống nhau không, có cùng nguyên tắc và vòng đời giống nhau hay có vòng đời và nguyên tắc khác nhau? Thông thường, khi nói về Tích hợp và Phát triển liên tục, mọi người đều quên rằng còn có mã cơ sở hạ tầng. Và gần đây ngày càng có nhiều chuyện như vậy. Và tất cả những quy tắc này có nên được đưa đến đó không?
Thậm chí không phải như vậy, nó sẽ rất tuyệt vì nó sẽ làm cho cuộc sống dễ dàng hơn theo cách tương tự. Ngay khi chúng tôi làm việc với mã, không phải với tập lệnh bash mà chúng tôi có mã bình thường.
Dừng lại, dừng lại, tập lệnh bash cũng là mã. Đừng chạm vào tình cũ của tôi.
Được rồi, tôi sẽ không chà đạp lên ký ức của bạn. Cá nhân tôi không thích bash. Nó lúc nào cũng xấu xí và đáng sợ. Và nó thường xuyên bị hỏng một cách khó lường, đó là lý do tại sao tôi không thích nó. Nhưng được rồi, giả sử bạn có mã bash. Có lẽ tôi thực sự không hiểu và có những khuôn khổ thử nghiệm thông thường ở đó. Tôi chỉ không biết thôi. Và chúng tôi nhận được những lợi ích tương tự.
Ngay khi chúng tôi làm việc với cơ sở hạ tầng dưới dạng mã, chúng tôi sẽ gặp phải tất cả các vấn đề tương tự như các nhà phát triển. Một vài tháng trước, tôi gặp phải tình huống một đồng nghiệp gửi cho tôi yêu cầu kéo 1 dòng trong bash. Và bạn đi chơi ở buổi đánh giá trong 000 giờ. Những vấn đề tương tự phát sinh. Nó vẫn là mã. Và nó vẫn là sự hợp tác. Ví dụ: chúng tôi gặp khó khăn với yêu cầu kéo và chúng tôi gặp khó khăn với thực tế là chúng tôi đang giải quyết các xung đột hợp nhất giống nhau trong cùng một bash.
Bây giờ tôi đang rất tích cực xem xét toàn bộ vấn đề này trên chương trình cơ sở hạ tầng đẹp nhất. Bây giờ tôi đã đưa Pulumi vào cơ sở hạ tầng. Đây là lập trình ở dạng thuần túy nhất. Ở đó, nó thậm chí còn đẹp hơn, bởi vì tôi có tất cả các khả năng của một ngôn ngữ lập trình, tức là tôi đã thực hiện chuyển đổi đẹp mắt từ màu xanh lam với cùng một if và mọi thứ đều ổn. Tức là sự thay đổi của tôi đã có trong bản gốc. Mọi người đều có thể nhìn thấy anh ấy. Các kỹ sư khác biết về nó. Nó đã ảnh hưởng đến một cái gì đó ở đó. Tuy nhiên, nó không được kích hoạt cho tất cả các cơ sở hạ tầng. Ví dụ: nó được bật cho băng ghế thử nghiệm của tôi. Vì vậy, để trả lời câu hỏi của bạn một lần nữa, điều đó là cần thiết. Nó giúp cuộc sống của chúng ta dễ dàng hơn, với tư cách là các kỹ sư làm việc với mã, theo cách tương tự.
Nếu có ai khác có câu hỏi?
Tôi có một câu hỏi. Tôi muốn tiếp tục cuộc thảo luận với Oleg. Nói chung, tôi nghĩ rằng bạn đúng, rằng nếu một nhiệm vụ mất một tháng để hoàn thành thì bạn có vấn đề với kiến trúc, bạn có vấn đề với việc phân tích, phân rã, lập kế hoạch, v.v. Nhưng tôi có cảm giác rằng nếu bạn bắt đầu cố gắng sống theo Tích hợp liên tục, khi đó bạn sẽ bắt đầu khắc phục nỗi đau bằng cách lập kế hoạch, bởi vì bạn sẽ không thoát khỏi nó ở bất kỳ nơi nào khác.
(Oleg) Vâng, đúng vậy. Nỗ lực này có thể so sánh được với bất kỳ hoạt động thay đổi văn hóa nghiêm túc nào khác. Điều khó khắc phục nhất là thói quen, đặc biệt là thói quen xấu. Và nếu để thực hiện phương pháp này, bạn cần phải thay đổi nghiêm túc thói quen của những người xung quanh: nhà phát triển, quản lý, giám đốc sản xuất, thì những điều bất ngờ đang chờ đợi bạn.
Có thể có những điều bất ngờ gì? Giả sử bạn quyết định rằng bạn sẽ hòa nhập thường xuyên hơn. Và bạn có một số thứ khác gắn liền với sự tích hợp, ví dụ như các đồ tạo tác. Và ví dụ, trong công ty của bạn, có một chính sách quy định mọi hiện vật phải được hạch toán theo một cách nào đó trong một loại hệ thống lưu trữ hiện vật nào đó. Và phải mất một thời gian. Một người cần đánh dấu vào ô rằng anh ta, với tư cách là người quản lý phát hành, đã kiểm tra tạo phẩm này để đảm bảo nó đã sẵn sàng để phát hành trong sản xuất. Nếu mất 5-10-15 phút nhưng bạn thực hiện bố cục mỗi tuần một lần, thì việc dành nửa giờ mỗi tuần một lần là một khoản thuế nhỏ.
Nếu bạn thực hiện Tích hợp liên tục 10 lần một ngày thì 10 lần cần được nhân với 30 phút. Và điều này vượt quá lượng thời gian làm việc của người quản lý phát hành này. Anh ấy chỉ cảm thấy mệt mỏi khi làm việc đó. Có chi phí cố định cho một số thực hành. Đó là tất cả.
Và bạn cần phải hủy quy tắc này để không còn làm những việc rác rưởi như vậy nữa, tức là bạn không tự gán bằng cấp tương ứng với thứ gì đó. Bạn đang dựa hoàn toàn vào một số bộ kiểm tra mức độ sẵn sàng tự động.
Và nếu bạn cần bằng chứng từ ai đó để ông chủ ký và bạn không bắt tay vào sản xuất nếu Vasya không nói rằng ông ấy cho phép, v.v. - tất cả những điều vô nghĩa này sẽ cản trở người thực hành. Bởi vì nếu có một số hoạt động liên quan đến thuế thì mọi thứ sẽ tăng gấp 100 lần. Vì vậy, ca làm việc thường sẽ không được mọi người chào đón một cách vui vẻ. Vì thói quen của con người khó thay đổi.
Khi một người làm công việc thường ngày của mình, anh ta gần như làm việc đó mà không cần suy nghĩ. Tải nhận thức của cô ấy bằng không. Anh ấy chỉ chơi đùa với nó, anh ấy đã có sẵn một danh sách kiểm tra trong đầu, anh ấy đã làm nó hàng nghìn lần. Và ngay khi bạn đến và nói với anh ấy: “Hãy hủy bỏ bài tập này và giới thiệu một bài tập mới bắt đầu từ thứ Hai,” đối với anh ấy, điều đó trở thành một gánh nặng nhận thức mạnh mẽ. Và nó đến với mọi người cùng một lúc.
Vì vậy, điều đơn giản nhất, mặc dù không phải ai cũng có đủ khả năng chi trả cho thứ xa xỉ này, nhưng đây là điều tôi luôn làm, đây là điều sau đây. Nếu một dự án mới bắt đầu, thì thông thường tất cả các hoạt động chưa được kiểm chứng sẽ ngay lập tức được đưa vào dự án này. Mặc dù dự án còn non trẻ nhưng chúng tôi thực sự không mạo hiểm bất cứ điều gì. Chưa có Prod, chưa có gì để tiêu diệt. Vì vậy, nó có thể được sử dụng như là đào tạo. Cách tiếp cận này hoạt động. Nhưng không phải công ty nào cũng có cơ hội bắt đầu những dự án như vậy thường xuyên. Mặc dù điều này cũng hơi lạ nhưng vì hiện nay đang có sự chuyển đổi số hoàn toàn nên mọi người đều phải triển khai thử nghiệm để theo kịp đối thủ.
Ở đây bạn đi đến kết luận rằng trước tiên bạn phải hiểu những gì bạn cần làm. Thế giới không lý tưởng và sản phẩm cũng không lý tưởng.
Vâng, những điều này được kết nối với nhau.
Các doanh nghiệp cũng không phải lúc nào cũng hiểu rằng họ cần phải đi theo con đường này.
Có một tình huống mà không thể thay đổi được gì cả. Đây là tình huống có nhiều áp lực hơn cho đội. Đội đã khá kiệt sức rồi. Cô ấy không có thời gian rảnh rỗi cho bất kỳ thí nghiệm nào. Họ làm việc trên các tính năng từ sáng đến tối. Và việc quản lý ngày càng có ít tính năng hơn. Ngày càng cần nhiều hơn nữa. Trong tình huống như vậy, không thể có sự thay đổi nào cả. Nhóm chỉ có thể được thông báo rằng ngày mai chúng tôi sẽ làm giống như ngày hôm qua, chúng tôi chỉ cần tạo thêm một chút tính năng. Theo nghĩa này, không thể chuyển đổi sang bất kỳ thực hành nào. Đây là một tình huống kinh điển khi không có thời gian mài rìu, cây cối cần phải chặt hạ nên họ chặt bằng một chiếc rìu cùn. Không có lời khuyên đơn giản ở đây.
(Dmitry) Tôi sẽ đọc lời giải thích từ cuộc trò chuyện: “Nhưng chúng tôi cần nhiều thông tin kiểm tra ở các cấp độ khác nhau. Bao nhiêu thời gian được phân bổ cho các bài kiểm tra? Nó hơi tốn kém và mất nhiều thời gian.”
(Oleg) Đây là một quan niệm sai lầm kinh điển. Cần có đủ bài kiểm tra để bạn tự tin. Tích hợp liên tục không phải là việc 100% các bài kiểm tra được thực hiện trước và chỉ sau đó bạn mới bắt đầu áp dụng phương pháp này. Tích hợp liên tục làm giảm tải nhận thức của bạn do thực tế là mỗi thay đổi mà bạn nhìn thấy bằng mắt thường rõ ràng đến mức bạn hiểu liệu nó có phá vỡ thứ gì đó hay không, ngay cả khi không cần kiểm tra. Bạn có thể nhanh chóng kiểm tra điều này trong đầu vì những thay đổi rất nhỏ. Ngay cả khi bạn chỉ có người kiểm tra thủ công thì họ cũng sẽ dễ dàng hơn. Bạn lăn ra và nói: "Nhìn xem, có cái gì bị gãy không?" Họ kiểm tra và nói: “Không, không có gì bị hỏng cả”. Bởi vì người thử nghiệm biết nơi để tìm. Bạn có một cam kết liên quan đến một đoạn mã. Và điều này được khai thác bởi hành vi cụ thể.
Ở đây bạn, tất nhiên, được tô điểm.
(Dmitry) Tôi không đồng ý ở đây. Có một phương pháp thực hành - phát triển dựa trên thử nghiệm sẽ giúp bạn thoát khỏi điều này.
(Oleg) Chà, tôi vẫn chưa đạt đến mức đó. Ảo tưởng đầu tiên là bạn cần phải viết 100% các bài kiểm tra hoặc bạn hoàn toàn không cần thực hiện Tích hợp liên tục. Không phải như vậy. Đây là hai thực hành song song. Và họ không phụ thuộc trực tiếp. Phạm vi kiểm tra của bạn phải tối ưu. Tối ưu - điều này có nghĩa là bản thân bạn tin tưởng rằng chất lượng của chủ mà chủ của bạn vẫn duy trì sau khi cam kết cho phép bạn tự tin nhấn nút “Triển khai” vào một tối thứ Sáu say xỉn. Làm thế nào để bạn đạt được điều này? Thông qua xem xét, thông qua phạm vi bao phủ, thông qua giám sát tốt.
Giám sát tốt không thể phân biệt được với kiểm tra. Nếu bạn chạy thử nghiệm một lần trên sản phẩm trước, thì họ sẽ kiểm tra tất cả tập lệnh người dùng của bạn một lần và thế là xong. Và nếu bạn chạy chúng trong một vòng lặp vô tận, thì đây là hệ thống giám sát đã triển khai của bạn, hệ thống này không ngừng kiểm tra mọi thứ - cho dù nó có bị lỗi hay không. Trong trường hợp này, sự khác biệt duy nhất là nó được thực hiện một hay hai lần. Một bộ thử nghiệm rất tốt... chạy liên tục, đây là giám sát. Và việc giám sát thích hợp phải như thế này.
Và do đó, làm thế nào chính xác bạn sẽ đạt được trạng thái này khi bạn chuẩn bị sẵn sàng vào tối thứ Sáu và về nhà lại là một câu hỏi khác. Có lẽ bạn chỉ là một kẻ đê tiện táo bạo.
Hãy quay lại một chút về Tích hợp liên tục. Chúng tôi lao vào một phương pháp thực hành phức tạp hơi khác một chút.
Và ảo tưởng thứ hai là MVP, theo họ, cần phải được thực hiện nhanh chóng, vì vậy ở đó không cần phải kiểm tra gì cả. Chắc chắn là không theo cách đó. Thực tế là khi bạn viết một câu chuyện người dùng trong MVP, bạn có thể phát triển nó ngay lập tức, tức là bạn nghe nói rằng có một loại câu chuyện người dùng nào đó và ngay lập tức chạy mã nó hoặc bạn có thể làm việc bằng TDD. Và theo TDD, như thực tế cho thấy, việc này không mất nhiều thời gian hơn, tức là các bài kiểm tra là một tác dụng phụ. Việc thực hành TDD không phải là kiểm tra. Bất chấp cái được gọi là Phát triển dựa trên thử nghiệm, nó hoàn toàn không phải về thử nghiệm. Đây cũng là một cách tiếp cận kiến trúc. Đây là một cách tiếp cận để viết chính xác những gì cần thiết và không viết những gì không cần thiết. Đây là một phương pháp thực hành tập trung vào lần lặp lại suy nghĩ tiếp theo của bạn trong việc tạo ra kiến trúc ứng dụng.
Vì vậy, để thoát khỏi những ảo tưởng này không phải là điều dễ dàng. MVP và các bài kiểm tra không mâu thuẫn với nhau. Thậm chí, ngược lại, nếu bạn thực hiện MVP bằng cách luyện tập TDD, thì bạn sẽ làm điều đó tốt hơn và nhanh hơn so với khi bạn thực hiện nó mà không cần luyện tập mà chỉ thực hiện trên một quả bóng.
Đây là một ý tưởng rất khó hiểu và phức tạp. Khi bạn nghe rằng bây giờ tôi sẽ viết nhiều bài kiểm tra hơn và đồng thời tôi sẽ làm điều gì đó nhanh hơn, điều đó nghe có vẻ hoàn toàn không thỏa đáng.
(Dmitry) Nhiều người ở đây khi gọi MVP là lười viết gì đó bình thường. Và đây vẫn là những điều khác nhau. Không cần thiết phải biến MVP thành thứ gì đó tồi tệ không có tác dụng.
Vâng, vâng, bạn nói đúng.
Và rồi đột nhiên đạt được MVP trong sản phẩm.
Mãi mãi.
Và TDD nghe có vẻ rất bất thường khi bạn nghe nói rằng bạn viết bài kiểm tra và dường như làm được nhiều việc hơn. Nghe có vẻ rất lạ nhưng thực tế theo cách này nó diễn ra nhanh hơn và đẹp hơn. Khi bạn viết một bài kiểm thử, bạn đã suy nghĩ rất nhiều trong đầu về việc mã nào sẽ được gọi và cách thức cũng như hành vi mà chúng ta mong đợi từ nó. Bạn không chỉ nói rằng tôi đã viết một số chức năng và nó thực hiện được điều gì đó. Lúc đầu bạn nghĩ rằng cô ấy có điều kiện như vậy, cô ấy sẽ được kêu gọi theo cách này và cách khác. Bạn đề cập đến vấn đề này bằng các bài kiểm tra và từ đó bạn hiểu giao diện của bạn sẽ trông như thế nào bên trong mã của bạn. Điều này ảnh hưởng rất lớn đến kiến trúc. Mã của bạn tự động trở nên mô-đun hơn, bởi vì trước tiên bạn cố gắng hiểu cách bạn sẽ kiểm tra nó và chỉ sau đó mới viết nó.
Điều xảy ra với tôi với TDD là tại một thời điểm nào đó, tôi đã thuê một người cố vấn về Ruby khi tôi vẫn còn là một lập trình viên Ruby. Và anh ấy nói: “Hãy làm theo TDD.” Tôi nghĩ: “Chết tiệt, giờ mình phải viết thêm gì đó.” Và chúng tôi đã đồng ý rằng trong vòng hai tuần tôi sẽ viết tất cả mã hoạt động bằng Python bằng TDD. Sau hai tuần, tôi nhận ra rằng mình không muốn quay lại. Sau hai tuần cố gắng áp dụng điều này ở mọi nơi, bạn nhận ra rằng việc suy nghĩ đã trở nên dễ dàng hơn rất nhiều đối với bạn. Nhưng điều này không rõ ràng nên tôi khuyên mọi người rằng nếu bạn cảm thấy TDD khó khăn, tốn thời gian và không cần thiết, hãy thử gắn bó với nó chỉ trong hai tuần. Hai là đủ cho tôi.
(Dmitry) Chúng ta có thể mở rộng ý tưởng này từ góc độ vận hành cơ sở hạ tầng. Trước khi tung ra bất cứ thứ gì mới, chúng tôi sẽ theo dõi và sau đó tung ra. Trong trường hợp này, việc giám sát trở thành thử nghiệm bình thường đối với chúng tôi. Và có sự phát triển thông qua giám sát. Nhưng hầu như ai cũng bảo dài, tôi lười, tôi viết nháp tạm thời. Nếu chúng tôi đã thực hiện giám sát bình thường, chúng tôi sẽ hiểu được trạng thái của hệ thống CI. Và hệ thống CI có rất nhiều giám sát. Chúng tôi hiểu trạng thái của hệ thống, chúng tôi hiểu những gì bên trong nó. Và trong quá trình phát triển, chúng tôi chỉ làm cho hệ thống đạt được trạng thái mong muốn.
Những thực hành này đã được biết đến từ lâu. Chúng tôi đã thảo luận vấn đề này khoảng 4 năm trước. Nhưng trong 4 năm thực tế không có gì thay đổi.
Nhưng về lưu ý này, tôi đề nghị kết thúc cuộc thảo luận chính thức.
Video (được chèn dưới dạng phần tử phương tiện nhưng vì lý do nào đó không hoạt động):
Nguồn: www.habr.com