Báo cáo sẽ nói về một số phương pháp thực hành DevOps, nhưng từ quan điểm của nhà phát triển. Thông thường, tất cả các kỹ sư tham gia DevOps đều đã có vài năm kinh nghiệm quản trị. Nhưng điều này không có nghĩa là không có chỗ cho nhà phát triển ở đây. Thông thường, các nhà phát triển đang bận sửa “lỗi nghiêm trọng khẩn cấp tiếp theo trong ngày” và họ thậm chí không có thời gian để xem nhanh lĩnh vực DevOps. Theo cách hiểu của tác giả, DevOps trước hết là lẽ thường. Thứ hai, đó là cơ hội để làm việc hiệu quả hơn. Nếu bạn là một nhà phát triển, có ý thức chung và muốn trở thành người làm việc nhóm hiệu quả hơn thì báo cáo này là dành cho bạn.
Hãy để tôi tự giới thiệu, tôi hoàn toàn thừa nhận rằng trong phòng có những người không biết tôi. Tên tôi là Anton Boyko, tôi là MVP của Microsoft Azure. MVP là gì? Đây là Model-View-Presenter. Model-View-Presenter chính xác là tôi.
Ngoài ra, tôi hiện đang giữ vị trí kiến trúc sư giải pháp tại Ciklum. Và mới đây tôi đã mua cho mình một miền đẹp như vậy và tôi đã cập nhật email của mình, email mà tôi thường hiển thị trong các buổi thuyết trình. Bạn có thể viết thư cho tôi tại: me [dog] byokoant.pro. Bạn có thể gửi email cho tôi với câu hỏi. Tôi thường trả lời họ. Điều duy nhất là tôi không muốn nhận những câu hỏi qua email liên quan đến hai chủ đề: chính trị và tôn giáo. Bạn có thể viết thư cho tôi về mọi thứ khác qua email. Một thời gian sẽ trôi qua, tôi sẽ trả lời.
Nói một vài từ về bản thân bạn:
- Tôi đã làm việc trong lĩnh vực này được 10 năm rồi.
- Tôi đã làm việc tại Microsoft.
- Tôi là người sáng lập cộng đồng Azure Ukraina mà chúng tôi đã thành lập vào năm 2014. Và chúng tôi vẫn có nó và đang phát triển nó.
- Tôi cũng là cha của người sáng lập hội nghị Azure mà chúng tôi đang tổ chức tại Ukraine.
- Tôi cũng giúp tổ chức Global Azure Bootcamp ở Kyiv.
- Như tôi đã nói, tôi là MVP của Microsoft Azure.
- Tôi phát biểu tại các hội nghị khá thường xuyên. Tôi thực sự thích phát biểu tại các hội nghị. Trong năm qua tôi đã có thể biểu diễn khoảng 40 lần. Nếu bạn đi ngang qua Ukraine, Belarus, Ba Lan, Bulgaria, Thụy Điển, Đan Mạch, Hà Lan, Tây Ban Nha hoặc cho hoặc nhận một quốc gia khác ở Châu Âu, thì rất có thể khi bạn tham dự một hội nghị có chủ đề về đám mây trong luồng của nó, bạn có thể thấy tôi trong danh sách diễn giả.
- Tôi cũng là một người hâm mộ Star Trek.
Hãy nói một chút về Chương trình nghị sự. Chương trình nghị sự của chúng tôi rất đơn giản:
- Chúng ta sẽ nói về DevOps là gì. Hãy nói tại sao điều này lại quan trọng. Trước đây, DevOps là từ khóa mà bạn viết trong sơ yếu lý lịch của mình và ngay lập tức nhận được +$500 tiền lương. Bây giờ, bạn cần viết blockchain, chẳng hạn như trong sơ yếu lý lịch của mình để nhận được +500 đô la vào tiền lương của mình.
- Và sau đó, khi chúng ta hiểu một chút về điều này là gì, chúng ta sẽ nói về thực hành DevOps là gì. Nhưng không phải nói nhiều về bối cảnh của DevOps nói chung mà là về những phương pháp thực hành DevOps có thể được các nhà phát triển quan tâm. Tôi sẽ cho bạn biết lý do tại sao họ có thể khiến bạn quan tâm. Tôi sẽ cho bạn biết lý do tại sao bạn nên làm điều này và nó có thể giúp bạn bớt đau đớn như thế nào.
Một hình ảnh truyền thống được nhiều người thể hiện. Đây là điều xảy ra ở nhiều dự án. Đây là lúc chúng tôi có các bộ phận phát triển và vận hành hỗ trợ phần mềm của mình. Và các bộ phận này không liên lạc với nhau.
Có lẽ, nếu bạn không thể cảm nhận rõ ràng điều đó ở bộ phận DevOps và vận hành, bạn có thể rút ra sự tương đồng với bộ phận Dev và QA. Có những người phát triển phần mềm và có những người QA không tốt theo quan điểm của nhà phát triển. Ví dụ: tôi đưa mã tuyệt vời của mình vào kho lưu trữ, và có một số kẻ vô lại đang ngồi đó trả lại mã này cho tôi và nói rằng mã của bạn tệ.
Tất cả điều này xảy ra bởi vì mọi người không giao tiếp với nhau. Và họ ném một số gói hàng, một số ứng dụng cho nhau qua bức tường hiểu lầm nào đó và cố gắng làm điều gì đó với chúng.
Chính bức tường này mà văn hóa DevOps được thiết kế để phá hủy, tức là. buộc mọi người phải giao tiếp với nhau và ít nhất cũng hiểu được những người khác nhau trong dự án làm gì và tại sao công việc của họ lại quan trọng.
Và khi chúng ta nói về DevOps, sẽ có người nói với bạn rằng DevOps là khi dự án có sự tích hợp liên tục; ai đó sẽ nói rằng DevOps là như vậy nếu dự án triển khai thực hành “cơ sở hạ tầng dưới dạng mã”; ai đó sẽ nói rằng bước đầu tiên của DevOps là phân nhánh tính năng, gắn cờ tính năng.
Về cơ bản, tất cả điều này đều đúng theo cách riêng của nó. Nhưng đây chỉ là những thực hành tối thượng mà chúng ta có. Trước khi chuyển sang các phương pháp thực hành này, tôi khuyên bạn nên xem trang trình bày này, trong đó trình bày 3 giai đoạn triển khai phương pháp Dev-Ops trong dự án, trong công ty của bạn.
Slide này còn có tên không chính thức thứ hai. Bạn có thể search trên mạng để biết 3 chàng lính ngự lâm của DevOps là gì. Có thể bạn sẽ tìm thấy bài viết này. Tại sao lại là 3 chàng lính ngự lâm? Bên dưới có ghi: con người, quy trình và sản phẩm, tức là PPP – Porthos, Porthos và Porthos. Dưới đây là 3 chàng lính ngự lâm của DevOps. Bài viết này mô tả chi tiết hơn tại sao điều này lại quan trọng và nó đòi hỏi những gì.
Khi bạn bắt đầu triển khai văn hóa DevOps, điều quan trọng là nó phải được triển khai theo thứ tự sau.
Ban đầu bạn cần nói chuyện với mọi người. Và bạn cần giải thích cho mọi người nó là gì và làm thế nào họ có thể nhận được một số lợi ích từ nó.
Hội nghị của chúng tôi được gọi là DotNet Fest. Và như ban tổ chức đã nói với tôi, chúng tôi chủ yếu mời khán giả là các nhà phát triển đến đây, vì vậy tôi hy vọng rằng hầu hết những người trong hội trường đều tham gia vào quá trình phát triển.
Chúng ta sẽ nói về con người, chúng ta sẽ nói về những gì các nhà phát triển muốn làm hàng ngày. Họ muốn gì nhất? Họ muốn viết một số mã mới, sử dụng các khuôn khổ mới, tạo các tính năng mới. Các nhà phát triển ít mong muốn điều gì nhất? Sửa lỗi cũ. Tôi hy vọng bạn đồng ý với tôi. Đây là những gì các nhà phát triển muốn. Họ muốn viết các tính năng mới, họ không muốn sửa lỗi.
Số lượng lỗi mà một nhà phát triển cụ thể tạo ra phụ thuộc vào độ thẳng của cánh tay anh ta và mức độ chúng phát triển từ vai anh ta chứ không phải từ túi mông của anh ta. Tuy nhiên, khi chúng ta có một dự án lớn, đôi khi không thể theo dõi mọi thứ, vì vậy sẽ rất tốt nếu chúng ta sử dụng một số phương pháp giúp chúng ta viết mã ổn định hơn và chất lượng cao hơn.
QA muốn gì nhất? Tôi không biết họ có ở trong hội trường không. Thật khó để tôi nói rằng tôi muốn có QA, bởi vì tôi chưa bao giờ là QA. Và không có ý xúc phạm đến các chàng trai, người ta sẽ nói rằng tôi hy vọng mình sẽ không bao giờ làm vậy. Nhưng không phải vì tôi coi công việc của họ là vô nghĩa và vô ích, mà vì tôi không coi mình là người có thể làm công việc này một cách hiệu quả nên thậm chí tôi sẽ không cố gắng làm. Nhưng theo những gì tôi hiểu, điều QA không thích nhất là đi làm vào buổi sáng, liên tục chạy một số loại thử nghiệm hồi quy, giẫm lên những lỗi tương tự mà họ đã báo cáo cho các nhà phát triển 3 lần chạy nước rút trước và nói: “Khi nào bạn sẽ làm vậy? , Monsieur D 'Artagnan, sửa lỗi này đi.' Và ông D'Artagnan trả lời anh ta: "Vâng, vâng, vâng, tôi đã sửa nó rồi." Và làm thế nào mà tôi đã sửa được một lỗi và mắc phải 5 lỗi trong quá trình đó.
Những người hỗ trợ giải pháp này trong quá trình sản xuất muốn giải pháp này hoạt động mà không có lỗi, để họ không phải khởi động lại máy chủ vào thứ Sáu hàng tuần, khi tất cả những người bình thường đều đến quán bar. Các nhà phát triển đã triển khai vào thứ Sáu, các quản trị viên ngồi cho đến thứ Bảy, cố gắng hoàn thiện và sửa lỗi triển khai này.
Và khi bạn giải thích với mọi người rằng mục đích của họ là giải quyết những vấn đề tương tự, bạn có thể chuyển sang chính thức hóa các quy trình. Rất quan trọng. Tại sao? Bởi vì khi chúng tôi nói “chính thức hóa”, điều quan trọng là bạn phải mô tả cách các quy trình của bạn diễn ra ít nhất ở đâu đó trên một chiếc khăn ăn. Bạn cần hiểu rằng nếu bạn triển khai vào môi trường QA hoặc môi trường sản xuất chẳng hạn, thì việc này luôn diễn ra theo thứ tự này; ở các giai đoạn này, chúng tôi chạy các thử nghiệm đơn vị tự động và thử nghiệm giao diện người dùng chẳng hạn. Sau khi triển khai, chúng tôi kiểm tra xem quá trình triển khai diễn ra tốt hay kém. Nhưng bạn đã có một danh sách rõ ràng các hành động phải được lặp đi lặp lại nhiều lần khi triển khai vào môi trường sản xuất.
Và chỉ khi các quy trình của bạn được chính thức hóa, bạn mới bắt đầu chọn những sản phẩm giúp bạn tự động hóa các quy trình này.
Thật không may, tôi thường thấy điều này xảy ra ngược lại. Ngay khi có người nghe đến từ “DevOps”, họ ngay lập tức đề nghị cài đặt Jenkins, vì họ tin rằng ngay khi cài Jenkins là họ sẽ có DevOps. Họ đã cài đặt Jenkins, đọc các bài viết “Cách thực hiện” trên trang web của Jenkins, cố gắng nhồi nhét các quy trình vào các bài viết Cách thực hiện này, sau đó đến gặp mọi người và cúi xuống nói rằng cuốn sách nói rằng bạn cần phải làm theo cách này, vì vậy chúng tôi làm theo cách này.
Không phải Jenkins là một công cụ tồi. Tôi không có ý nói điều đó theo bất kỳ cách nào. Nhưng đây chỉ là một trong những sản phẩm. Và sản phẩm bạn sử dụng sẽ là quyết định cuối cùng của bạn và không phải là quyết định đầu tiên của bạn. Sản phẩm của bạn không nên bị thúc đẩy bởi việc thực hiện văn hóa và các phương pháp tiếp cận. Điều này rất quan trọng cần hiểu, đó là lý do tại sao tôi dành nhiều thời gian cho slide này và giải thích tất cả những điều này quá lâu.
Hãy nói về thực tiễn DevOps nói chung. Họ là ai? Sự khác biệt là gì? Làm thế nào để thử chúng? Tại sao chúng lại quan trọng?
Cách thực hành đầu tiên bạn có thể đã nghe nói đến có tên là Tích hợp liên tục. Có lẽ ai đó trong dự án có Tích hợp liên tục (CI).
Vấn đề lớn nhất là khi tôi hỏi một người: “Bạn có CI cho dự án không?” và anh ấy nói: “Có”, sau đó khi tôi hỏi anh ấy làm gì, anh ấy mô tả cho tôi toàn bộ quá trình tự động hóa. Điều này không hoàn toàn đúng.
Trên thực tế, hoạt động của CI chỉ nhằm mục đích tích hợp mã mà những người khác nhau viết vào một loại cơ sở mã duy nhất nào đó. Đó là tất cả.
Cùng với CI, thường có các phương pháp thực hành khác - chẳng hạn như Triển khai liên tục, Quản lý phát hành, nhưng chúng ta sẽ nói về điều đó sau.
Bản thân CI cho chúng ta biết rằng những người khác nhau viết mã và mã này phải được tích hợp liên tục vào một cơ sở mã duy nhất.
Điều này mang lại cho chúng ta điều gì và tại sao nó quan trọng? Nếu chúng ta có DotNet thì thật tốt, đó là một ngôn ngữ được biên dịch, chúng ta có thể biên dịch ứng dụng của mình. Nếu nó biên dịch thì đây đã là một dấu hiệu tốt. Điều này chưa có ý nghĩa gì cả, nhưng đó là dấu hiệu tốt đầu tiên mà ít nhất chúng ta có thể biên dịch được.
Sau đó, chúng tôi có thể chạy một số thử nghiệm, đây cũng là một cách thực hành riêng biệt. Các bài kiểm tra đều có màu xanh lá cây – đây là dấu hiệu tốt thứ hai. Nhưng một lần nữa, điều này không có nghĩa gì cả.
Nhưng tại sao bạn lại làm điều này? Tất cả các phương pháp mà tôi sẽ nói hôm nay đều có giá trị gần như nhau, tức là có những lợi ích gần giống nhau và cũng được đo lường theo cùng một cách.
Đầu tiên, nó cho phép bạn tăng tốc độ giao hàng. Làm thế nào điều này cho phép bạn tăng tốc độ giao hàng? Khi chúng tôi thực hiện một số thay đổi mới đối với cơ sở mã của mình, chúng tôi có thể ngay lập tức thử làm điều gì đó với mã này. Chúng tôi không đợi đến thứ Năm vì vào thứ Năm, chúng tôi phát hành nó cho Môi trường QA, chúng tôi làm điều đó ngay tại đây và ngay tại đây.
Tôi sẽ kể cho bạn nghe một câu chuyện buồn trong cuộc đời tôi. Đã lâu lắm rồi, khi tôi còn trẻ và đẹp trai. Bây giờ tôi đã trẻ, xinh đẹp, thông minh và khiêm tốn. Cách đây một thời gian tôi đã tham gia một dự án. Chúng tôi có một đội ngũ lớn gồm khoảng 30 nhà phát triển. Và chúng tôi đã có một dự án Enterprise rất lớn được phát triển trong khoảng 10 năm. Và chúng tôi có nhiều chi nhánh khác nhau. Trong kho lưu trữ, chúng tôi có một nhánh dành cho các nhà phát triển. Và có một nhánh hiển thị phiên bản mã đang được sản xuất.
Chi nhánh sản xuất chậm hơn 3 tháng so với chi nhánh dành cho các nhà phát triển. Điều đó có nghĩa là gì? Điều này có nghĩa là ngay khi tôi gặp một lỗi ở đâu đó và được đưa vào sản xuất do lỗi của nhà phát triển, do họ cho phép và do lỗi của QA, vì họ đã xem xét nó, thì điều này có nghĩa là nếu tôi nhận được một lỗi nhiệm vụ dành cho hotfix để sản xuất, sau đó tôi phải khôi phục các thay đổi mã của mình 3 tháng trước. Tôi phải nhớ lại những gì tôi đã có 3 tháng trước và cố gắng khắc phục nó ở đó.
Nếu bạn chưa có kinh nghiệm này, bạn có thể thử nó trong dự án nhà của mình. Điều quan trọng là đừng thử nó trên một sản phẩm thương mại. Viết một vài dòng mã, quên chúng trong sáu tháng, sau đó quay lại và cố gắng giải thích nhanh những dòng mã đó là gì và cách bạn có thể sửa hoặc tối ưu hóa chúng. Đó là một trải nghiệm rất, rất thú vị.
Nếu chúng tôi thực hành Tích hợp liên tục thì điều này cho phép chúng tôi kiểm tra nó bằng một số công cụ tự động ngay tại đây và ngay bây giờ, ngay sau khi tôi viết mã của mình. Điều này có thể không mang lại cho tôi bức tranh toàn cảnh, tuy nhiên, nó sẽ loại bỏ ít nhất một số rủi ro. Và nếu có bất kỳ lỗi tiềm ẩn nào, tôi sẽ biết về nó ngay bây giờ, nghĩa là sau vài phút. Tôi sẽ không cần phải quay lại 3 tháng. Tôi sẽ chỉ cần quay lại 2 phút. Một chiếc máy pha cà phê tốt thậm chí sẽ không có thời gian để pha cà phê trong 2 phút, điều đó thật tuyệt.
Điều này có giá trị là nó có thể được lặp lại nhiều lần trong mỗi dự án, tức là. không chỉ là cái bạn thiết lập nó. Bạn có thể lặp lại cả quá trình thực hành và bản thân CI sẽ được lặp lại cho mỗi thay đổi mới mà bạn thực hiện đối với dự án. Điều này cho phép bạn tối ưu hóa tài nguyên vì nhóm của bạn làm việc hiệu quả hơn. Bạn sẽ không còn gặp phải tình huống lỗi xảy ra với mã mà bạn đã làm việc với 3 tháng trước. Bạn sẽ không còn phải chuyển đổi ngữ cảnh khi ngồi và dành hai giờ đầu tiên để cố gắng hiểu điều gì đã xảy ra sau đó và đi sâu vào bản chất của ngữ cảnh trước khi bắt đầu sửa chữa điều gì đó.
Làm thế nào chúng ta có thể đo lường sự thành công hay thất bại của phương pháp này? Nếu bạn báo cáo với sếp lớn về những gì chúng tôi đã triển khai trong dự án CI, ông ấy sẽ nghe blah blah blah. Chúng tôi đã triển khai nó, được rồi, nhưng tại sao, nó mang lại cho chúng tôi điều gì, chúng tôi đo lường nó như thế nào, chúng tôi triển khai nó đúng hay sai như thế nào?
Đầu tiên là nhờ CI, chúng tôi có thể triển khai ngày càng thường xuyên hơn và chính xác hơn vì mã của chúng tôi có khả năng ổn định hơn. Tương tự như vậy, thời gian tìm lỗi của chúng tôi giảm đi và thời gian sửa lỗi này cũng giảm đi chính xác vì lý do chúng tôi nhận được câu trả lời từ hệ thống ngay tại đây và ngay bây giờ, mã của chúng tôi có vấn đề gì.
Một phương pháp thực hành khác mà chúng tôi có là phương pháp Kiểm thử tự động, phương pháp này thường đi kèm với phương pháp thực hành CI. Họ đi đôi với nhau.
Điều quan trọng cần hiểu ở đây là gì? Điều quan trọng là phải hiểu rằng các bài kiểm tra của chúng tôi khác nhau. Và mỗi bài kiểm tra tự động đều nhằm mục đích giải quyết các vấn đề của chính nó. Ví dụ: chúng tôi có các bài kiểm tra đơn vị cho phép chúng tôi kiểm tra một mô-đun riêng biệt, tức là. Nó hoạt động như thế nào trong chân không? Điều này tốt.
Chúng tôi cũng có các thử nghiệm tích hợp cho phép chúng tôi hiểu cách các mô-đun khác nhau tích hợp với nhau. Nó cũng tốt.
Chúng tôi có thể có các thử nghiệm tự động hóa giao diện người dùng cho phép chúng tôi kiểm tra xem hoạt động với giao diện người dùng có đáp ứng các yêu cầu nhất định do khách hàng đặt ra hay không, v.v.
Các thử nghiệm cụ thể mà bạn chạy có thể ảnh hưởng đến tần suất bạn chạy chúng. Bài kiểm tra đơn vị thường được viết ngắn và nhỏ. Và chúng có thể được tung ra thường xuyên.
Nếu chúng ta đang nói về thử nghiệm tự động hóa giao diện người dùng thì sẽ tốt nếu dự án của bạn có quy mô nhỏ. Các thử nghiệm tự động hóa giao diện người dùng của bạn có thể mất một khoảng thời gian thích hợp. Nhưng thông thường, kiểm thử tự động hóa giao diện người dùng là việc phải mất vài giờ đối với một dự án lớn. Và thật tốt nếu chỉ trong vài giờ. Điều duy nhất là không có ích gì khi chạy chúng cho mọi bản dựng. Thật ý nghĩa khi chạy chúng vào ban đêm. Và khi mọi người đến làm việc vào buổi sáng: cả người thử nghiệm và nhà phát triển, họ nhận được một loại báo cáo nào đó rằng chúng tôi đã chạy thử nghiệm tự động giao diện người dùng vào ban đêm và nhận được những kết quả này. Và ở đây, một giờ làm việc của một máy chủ sẽ kiểm tra xem sản phẩm của bạn có đáp ứng một số yêu cầu hay không sẽ rẻ hơn nhiều so với một giờ làm việc của cùng một kỹ sư QA, ngay cả khi anh ta là kỹ sư QA cấp dưới làm việc cho thực phẩm và cảm ơn. Dù sao đi nữa, một giờ vận hành máy sẽ rẻ hơn. Đây là lý do tại sao việc đầu tư vào nó là hợp lý.
Tôi có một dự án khác mà tôi đang thực hiện. Chúng tôi đã có hai tuần chạy nước rút cho dự án này. Dự án có quy mô lớn, quan trọng đối với lĩnh vực tài chính và không thể để xảy ra sai sót. Và sau hai tuần chạy nước rút, chu kỳ phát triển được tiếp nối bằng một quy trình thử nghiệm, mất thêm 4 tuần nữa. Hãy thử tưởng tượng quy mô của thảm kịch. Chúng tôi viết mã trong hai tuần, sau đó chúng tôi thực hiện nó theo CodeFreeze, đóng gói nó thành một phiên bản mới của ứng dụng và triển khai cho những người thử nghiệm. Những người thử nghiệm sẽ kiểm tra nó trong 4 tuần nữa, tức là. Trong khi họ đang thử nghiệm nó, chúng tôi có thời gian để chuẩn bị thêm hai phiên bản nữa cho họ. Đây thực sự là một trường hợp đáng buồn.
Và chúng tôi đã nói với họ rằng nếu bạn muốn làm việc hiệu quả hơn thì bạn nên triển khai các phương pháp Kiểm tra tự động vì đây là điều khiến bạn tổn thương ngay tại đây, ngay bây giờ.
Thực hành triển khai liên tục. Tuyệt vời, bạn đã xây dựng xong. Điều này đã tốt rồi. Mã của bạn đã được biên dịch. Bây giờ thật tuyệt khi triển khai bản dựng này trên một số môi trường. Giả sử trong môi trường dành cho nhà phát triển.
Tại sao nó lại quan trọng? Trước tiên, bạn có thể xem mức độ thành công của mình với chính quá trình triển khai. Tôi đã gặp những dự án như thế này, khi tôi hỏi: “Làm cách nào để triển khai phiên bản mới của ứng dụng?”, các anh chàng nói với tôi: “Chúng tôi tập hợp nó và đóng gói vào một kho lưu trữ zip. Chúng tôi gửi nó cho quản trị viên qua thư. Quản trị viên tải xuống và mở rộng kho lưu trữ này. Và cả văn phòng bắt đầu cầu nguyện rằng máy chủ sẽ nhận được phiên bản mới.”
Hãy bắt đầu với một cái gì đó đơn giản. Ví dụ: họ quên đưa CSS vào kho lưu trữ hoặc quên thay đổi hashtag trong tên tệp java-script. Và khi chúng ta đưa ra yêu cầu tới máy chủ, trình duyệt cho rằng nó đã có sẵn file java-script này và quyết định không tải xuống. Và có một phiên bản cũ, thiếu một cái gì đó. Nói chung, có thể có nhiều vấn đề. Do đó, việc thực hành Triển khai liên tục cho phép bạn ít nhất kiểm tra xem điều gì sẽ xảy ra nếu bạn chụp một hình ảnh tham chiếu rõ ràng và tải nó lên một môi trường mới hoàn toàn sạch sẽ. Bạn có thể thấy điều này dẫn đến đâu.
Ngoài ra, khi bạn tích hợp mã với nhau, tức là. giữa lệnh, điều này cũng cho phép bạn xem nó trông như thế nào trên giao diện người dùng.
Một trong những vấn đề xảy ra khi sử dụng nhiều tập lệnh java thuần túy là hai nhà phát triển đã khai báo một cách vội vàng một biến có cùng tên trong đối tượng cửa sổ. Và sau đó, tùy thuộc vào may mắn của bạn. File java-script của ai được kéo ra thứ hai sẽ ghi đè lên những thay đổi của file kia. Nó cũng rất thú vị. Bạn bước vào: thứ này hiệu quả với người này, thứ khác không hiệu quả với người khác. Và thật “tuyệt vời” khi tất cả đều được đưa vào sản xuất.
Cách thực hành tiếp theo mà chúng tôi thực hiện là thực hành Khôi phục Tự động, cụ thể là quay lại phiên bản trước của ứng dụng.
Tại sao điều này lại quan trọng đối với các nhà phát triển? Vẫn có những người còn nhớ về những năm 90 xa xôi, khi máy tính còn lớn và các chương trình còn nhỏ. Và cách duy nhất để phát triển web là thông qua PHP. Mặc dù vậy, không phải PHP là một ngôn ngữ xấu.
Nhưng vấn đề lại khác. Khi chúng tôi triển khai phiên bản mới của trang web php, chúng tôi đã triển khai nó như thế nào? Thông thường chúng tôi đã mở Far Manager hoặc thứ gì đó khác. Và tải những tập tin này lên FTP. Và chúng tôi chợt nhận ra mình mắc một lỗi nhỏ nào đó, ví dụ như quên đặt dấu chấm phẩy hoặc quên đổi mật khẩu cho cơ sở dữ liệu, lại có mật khẩu cho cơ sở dữ liệu, nằm trên máy chủ cục bộ. Và chúng tôi quyết định kết nối nhanh với FTP và chỉnh sửa các tập tin ngay tại đó. Đây chỉ là lửa! Đây là những gì đã được phổ biến trong những năm 90.
Nhưng nếu bạn chưa xem lịch thì thập niên 90 đã cách đây gần 30 năm. Bây giờ mọi thứ đang diễn ra hơi khác một chút. Và hãy thử tưởng tượng quy mô của thảm kịch khi họ nói với bạn: “Chúng tôi đã triển khai sản xuất, nhưng đã xảy ra sự cố ở đó. Đây là thông tin đăng nhập và mật khẩu FTP của bạn, hãy kết nối với sản phẩm và nhanh chóng sửa nó ở đó.” Nếu bạn là Chuck Norris, điều này sẽ hiệu quả. Nếu không, bạn có nguy cơ rằng nếu bạn sửa một lỗi, bạn sẽ mắc thêm 10 lỗi nữa. Đây chính xác là lý do tại sao phương pháp quay lại phiên bản trước này cho phép bạn đạt được nhiều thành tựu.
Ngay cả khi có điều gì đó tồi tệ bằng cách nào đó xảy ra ở đâu đó thì nó vẫn tệ, nhưng không gây tử vong. Bạn có thể quay lại phiên bản trước đó mà bạn có. Gọi nó là một bản sao lưu, nếu nó dễ hiểu hơn theo thuật ngữ đó. Bạn có thể quay lại phiên bản trước này và người dùng vẫn có thể làm việc với sản phẩm của bạn và bạn sẽ có đủ thời gian đệm. Bạn có thể bình tĩnh, không vội vàng, lấy tất cả những thứ này và kiểm tra cục bộ, sửa nó và sau đó tải lên phiên bản mới. Nó thực sự có ý nghĩa để làm điều này.
Bây giờ chúng ta hãy cố gắng kết hợp bằng cách nào đó hai cách thực hành trước đó lại với nhau. Chúng ta sẽ có cái thứ ba gọi là Quản lý phát hành.
Khi nói về Triển khai liên tục ở dạng cổ điển, chúng ta nói rằng chúng ta phải lấy mã từ một nhánh nào đó từ kho lưu trữ, biên dịch và triển khai nó. Thật tốt nếu chúng ta có cùng một môi trường. Nếu chúng ta có nhiều môi trường, điều này có nghĩa là chúng ta phải lấy mã mọi lúc, thậm chí từ cùng một cam kết. Chúng tôi sẽ lấy nó ra mọi lúc, chúng tôi sẽ xây dựng nó mọi lúc và chúng tôi sẽ triển khai nó sang một môi trường mới. Thứ nhất, đây là lúc, vì để xây dựng một dự án, nếu bạn có một dự án lớn và có từ những năm 90 thì có thể mất vài giờ.
Ngoài ra còn có một nỗi buồn khác. Khi bạn xây dựng, ngay cả trên cùng một máy, bạn sẽ xây dựng các nguồn giống nhau, bạn vẫn không có gì đảm bảo rằng máy này ở trạng thái giống như trong lần xây dựng trước.
Giả sử ai đó đã đến và cập nhật DotNet cho bạn hoặc ngược lại, ai đó đã quyết định xóa nội dung nào đó. Và sau đó, bạn có sự bất đồng về nhận thức rằng từ cam kết này hai tuần trước, chúng tôi đang xây dựng một bản dựng và mọi thứ đều ổn, nhưng bây giờ nó có vẻ giống như cùng một cỗ máy, cùng một cam kết, cùng một mã mà chúng tôi đang cố gắng xây dựng, nhưng nó không hoạt động . Bạn sẽ phải giải quyết vấn đề này trong một thời gian dài và thực tế không phải là bạn sẽ tìm ra được nó. Ít nhất, bạn sẽ làm hỏng thần kinh của mình rất nhiều.
Do đó, thực tiễn Quản lý phát hành đề xuất giới thiệu một bản tóm tắt bổ sung được gọi là kho lưu trữ hoặc thư viện hoặc thư viện tạo tác. Bạn có thể gọi nó là bất cứ điều gì bạn muốn.
Ý tưởng chính là ngay khi chúng tôi có một số loại cam kết ở đó, chẳng hạn như trong một nhánh mà chúng tôi sẵn sàng triển khai cho các môi trường khác nhau, chúng tôi sẽ thu thập các ứng dụng từ cam kết này và mọi thứ chúng tôi cần cho ứng dụng này, chúng tôi sẽ đóng gói nó vào kho lưu trữ zip và lưu nó vào một số nơi lưu trữ đáng tin cậy. Và từ bộ lưu trữ này, chúng tôi có thể lấy kho lưu trữ zip này bất cứ lúc nào.
Sau đó, chúng tôi lấy nó và tự động triển khai nó vào môi trường nhà phát triển. Chúng tôi đua ở đó và nếu mọi thứ đều ổn thì chúng tôi sẽ triển khai lên sân khấu. Nếu tất cả đều ổn, thì chúng tôi triển khai cùng một kho lưu trữ vào sản xuất, cùng các tệp nhị phân, được biên dịch chính xác một lần.
Ngoài ra, khi chúng tôi có một thư viện như thế này, nó cũng giúp chúng tôi giải quyết những rủi ro mà chúng tôi đã giải quyết ở trang trình bày trước khi nói về việc khôi phục về phiên bản trước. Nếu vô tình triển khai sai điều gì đó, bạn luôn có thể lấy bất kỳ phiên bản nào trước đó từ thư viện này và hủy triển khai nó sang các môi trường này theo cách tương tự. Điều này cho phép bạn dễ dàng quay lại phiên bản trước nếu có sự cố.
Có một thực hành tuyệt vời khác. Bạn và tôi đều hiểu rằng khi chúng ta khôi phục ứng dụng của mình về phiên bản trước, điều này có thể có nghĩa là chúng ta cũng cần cơ sở hạ tầng của phiên bản trước.
Khi nói về hạ tầng ảo, nhiều người cho rằng đây là thứ do quản trị viên thiết lập. Và nếu bạn cần, chẳng hạn, để có một máy chủ mới để thử nghiệm phiên bản mới của ứng dụng của mình, thì bạn phải viết một yêu cầu cho quản trị viên hoặc nhà phát triển. Devops sẽ mất 3 tuần cho việc này. Và sau 3 tuần, họ sẽ thông báo với bạn rằng chúng tôi đã cài đặt một máy ảo cho bạn, với một lõi, hai gigabyte RAM và một máy chủ Windows không có DotNet. Bạn nói: “Nhưng tôi muốn DotNet.” Họ: “Được rồi, hãy quay lại sau 3 tuần nữa.”
Ý tưởng là bằng cách sử dụng Cơ sở hạ tầng làm quy tắc, bạn có thể coi cơ sở hạ tầng ảo của mình chỉ như một tài nguyên khác.
Có lẽ, nếu bất kỳ ai trong số các bạn đang phát triển ứng dụng trên DotNet, chắc hẳn bạn đã nghe nói về một thư viện có tên là Entity Framework. Và bạn thậm chí có thể đã nghe nói rằng Entity Framework là một trong những cách tiếp cận mà Microsoft đang tích cực thúc đẩy. Để làm việc với cơ sở dữ liệu, đây là phương pháp được gọi là Code First. Đây là lúc bạn mô tả trong mã cách bạn muốn cơ sở dữ liệu của mình trông như thế nào. Và sau đó bạn triển khai ứng dụng. Nó kết nối với cơ sở dữ liệu, nó tự xác định bảng nào có và bảng nào không, đồng thời tạo ra mọi thứ bạn cần.
Bạn có thể làm tương tự với cơ sở hạ tầng của mình. Không có sự khác biệt giữa việc bạn cần cơ sở dữ liệu cho một dự án hay bạn cần máy chủ Windows cho dự án. Nó chỉ là một nguồn tài nguyên. Và bạn có thể tự động hóa việc tạo tài nguyên này, bạn có thể tự động hóa cấu hình của tài nguyên này. Theo đó, mỗi khi bạn muốn thử nghiệm một số khái niệm mới, một số cách tiếp cận mới, bạn sẽ không cần phải viết vé cho devops, bạn chỉ cần triển khai một cơ sở hạ tầng biệt lập cho mình từ các mẫu có sẵn, từ các tập lệnh tạo sẵn và triển khai nó có tất cả các thí nghiệm của bạn. Bạn có thể xóa điều này, nhận được một số kết quả và báo cáo thêm về nó.
Phương pháp tiếp theo, cũng tồn tại và cũng quan trọng nhưng ít người sử dụng, đó là Giám sát hiệu suất ứng dụng.
Tôi chỉ muốn nói một điều về Giám sát hiệu suất ứng dụng. Điều gì là quan trọng nhất trong thực hành này? Đây là tính năng Giám sát hiệu suất ứng dụng cũng giống như việc sửa chữa một căn hộ. Đây không phải là trạng thái cuối cùng, nó là một quá trình. Bạn cần phải làm điều đó thường xuyên.
Nói một cách tích cực, sẽ rất tốt nếu thực hiện Giám sát hiệu suất ứng dụng trên hầu hết mọi bản dựng, mặc dù, như bạn hiểu, điều này không phải lúc nào cũng có thể thực hiện được. Tuy nhiên, ở mức tối thiểu, nó cần phải được thực hiện cho mỗi lần phát hành.
Tại sao nó lại quan trọng? Bởi vì nếu bạn đột nhiên bị giảm hiệu suất thì bạn cần phải hiểu rõ lý do. Ví dụ: nếu nhóm của bạn có các lần chạy nước rút kéo dài hai tuần, thì ít nhất hai tuần một lần, bạn nên triển khai ứng dụng của mình đến một số máy chủ riêng biệt, nơi bạn có bộ xử lý, RAM, ổ đĩa, v.v. được cố định rõ ràng. Và chạy các bài kiểm tra hiệu suất tương tự đó . Bạn nhận được kết quả. Xem nó đã thay đổi như thế nào so với lần chạy nước rút trước.
Và nếu bạn phát hiện ra rằng mức rút vốn đã giảm mạnh ở đâu đó, điều đó có nghĩa là đó chỉ là do những thay đổi diễn ra trong hai tuần qua. Điều này sẽ cho phép bạn xác định và khắc phục sự cố nhanh hơn nhiều. Và một lần nữa, đây là những số liệu gần giống nhau để bạn có thể đo lường mức độ thành công của mình.
Bài thực hành tiếp theo mà chúng tôi có là bài thực hành Quản lý cấu hình. Có rất ít người thực hiện điều này một cách nghiêm túc. Nhưng tin tôi đi, đây thực sự là một việc rất nghiêm trọng.
Gần đây có một câu chuyện vui. Họ đến gặp tôi và nói: “Hãy giúp chúng tôi tiến hành kiểm tra bảo mật cho ứng dụng của chúng tôi.” Chúng tôi cùng nhau xem code rất lâu, họ kể cho tôi nghe về ứng dụng, vẽ sơ đồ. Và cộng hoặc trừ mọi thứ đều hợp lý, dễ hiểu, an toàn, nhưng có một NHƯNG! Họ có các tệp cấu hình trong kiểm soát nguồn của mình, bao gồm các tệp từ sản xuất có cơ sở dữ liệu IP, với thông tin đăng nhập và mật khẩu để kết nối với các cơ sở dữ liệu này, v.v.
Và tôi nói: “Các bạn, được rồi, các bạn đã đóng môi trường sản xuất của mình bằng tường lửa, nhưng việc bạn có thông tin đăng nhập và mật khẩu cho cơ sở dữ liệu sản xuất ngay trong phần kiểm soát nguồn và bất kỳ nhà phát triển nào cũng có thể đọc được đã là một rủi ro bảo mật rất lớn . Và cho dù ứng dụng của bạn có siêu an toàn đến đâu từ quan điểm mã, nếu bạn để nó trong kiểm soát nguồn, thì bạn sẽ không bao giờ vượt qua bất kỳ cuộc kiểm tra nào ở bất kỳ đâu.” Đó là những gì tôi đang nói về.
Quản lý cấu hình. Chúng tôi có thể có các cấu hình khác nhau trong các môi trường khác nhau. Ví dụ: chúng tôi có thể có thông tin đăng nhập và mật khẩu khác nhau cho cơ sở dữ liệu về QA, demo, môi trường sản xuất, v.v.
Cấu hình này cũng có thể được tự động hóa. Nó phải luôn tách biệt khỏi chính ứng dụng. Tại sao? Bởi vì bạn đã xây dựng ứng dụng một lần và sau đó ứng dụng không quan tâm đến việc bạn kết nối với máy chủ SQL thông qua IP như vậy hay IP như vậy, nên nó sẽ hoạt động như nhau. Do đó, nếu đột nhiên một trong các bạn vẫn mã hóa cứng chuỗi kết nối trong mã, thì hãy nhớ rằng tôi sẽ tìm bạn và trừng phạt bạn nếu bạn thấy mình cùng dự án với tôi. Điều này luôn được đặt trong một cấu hình riêng biệt, ví dụ: trong web.config.
Và cấu hình này đã được quản lý riêng biệt, tức là đây chính xác là thời điểm mà nhà phát triển và quản trị viên có thể đến ngồi trong cùng một phòng. Và nhà phát triển có thể nói: “Hãy nhìn xem, đây là các tệp nhị phân của ứng dụng của tôi. Họ làm việc. Ứng dụng cần có cơ sở dữ liệu để hoạt động. Ở đây bên cạnh các tệp nhị phân có một tập tin. Trong tệp này, trường này chịu trách nhiệm đăng nhập, đây là mật khẩu, đây là IP. Triển khai nó ở bất cứ đâu." Và nó đơn giản và rõ ràng đối với quản trị viên. Anh ta có thể triển khai nó thực sự ở bất cứ đâu bằng cách quản lý cấu hình này.
Và cách thực hành cuối cùng mà tôi muốn nói đến là một cách thực hành rất, rất liên quan đến mây. Và nó mang lại hiệu quả tối đa nếu bạn làm việc trên đám mây. Đây là Tự động loại bỏ môi trường của bạn.
Tôi biết có một số người tham dự hội nghị này từ các nhóm mà tôi làm việc cùng. Và với tất cả các nhóm mà tôi làm việc cùng, chúng tôi đều áp dụng phương pháp này.
Tại sao? Tất nhiên, sẽ thật tuyệt nếu mỗi nhà phát triển có một máy ảo hoạt động 24/7. Nhưng có lẽ đây là tin tức với bạn, có lẽ bạn đã không để ý nhưng bản thân nhà phát triển cũng không làm việc 24/7. Một nhà phát triển thường làm việc 8 giờ một ngày. Ngay cả khi anh ấy đi làm sớm, anh ấy vẫn ăn một bữa trưa thịnh soạn trong thời gian đó để đến phòng tập thể dục. Hãy để 12 giờ mỗi ngày khi nhà phát triển thực sự sử dụng những tài nguyên này. Theo luật pháp của chúng tôi, chúng tôi có 5 trong số 7 ngày trong một tuần được coi là ngày làm việc.
Theo đó, vào các ngày trong tuần, chiếc máy này không nên hoạt động 24 giờ mà chỉ làm việc 12 giờ, và vào cuối tuần, chiếc máy này hoàn toàn không hoạt động. Có vẻ như mọi thứ đều rất đơn giản, nhưng điều quan trọng cần nói ở đây là gì? Bằng cách triển khai phương pháp đơn giản này theo lịch trình cơ bản này, nó cho phép bạn giảm 70% chi phí duy trì các môi trường này, tức là bạn lấy giá của nhà phát triển, QA, demo, môi trường của mình và chia cho 3.
Câu hỏi đặt ra là làm gì với số tiền còn lại? Ví dụ: các nhà phát triển nên mua ReSharper nếu họ chưa mua. Hoặc tổ chức một bữa tiệc cocktail. Nếu trước đây bạn có một môi trường trong đó cả nhà phát triển và QA đều được chăn thả, thì bây giờ bạn có thể tạo 3 môi trường khác nhau sẽ tách biệt và mọi người sẽ không can thiệp lẫn nhau.
Về slide đo hiệu suất liên tục, làm thế nào chúng ta có thể so sánh hiệu suất nếu chúng ta có 1 bản ghi trong cơ sở dữ liệu của dự án, hai tháng sau có một triệu? Làm thế nào để hiểu lý do và mục đích của việc đo lường hiệu suất là gì?
Đây là một câu hỏi hay vì bạn phải luôn đo lường hiệu suất trên cùng một nguồn lực. Tức là bạn triển khai mã mới, bạn đo lường hiệu suất trên mã mới. Ví dụ: bạn cần kiểm tra các kịch bản hiệu suất khác nhau, giả sử bạn muốn kiểm tra cách ứng dụng hoạt động khi tải nhẹ, trong đó có 1 người dùng và kích thước cơ sở dữ liệu là 000 gigabyte. Bạn đo nó và nhận được những con số. Tiếp theo chúng ta lấy một kịch bản khác. Ví dụ: 5 người dùng, kích thước cơ sở dữ liệu là 5 terabyte. Chúng tôi đã nhận được kết quả và ghi nhớ chúng.
Điều gì quan trọng ở đây? Điều quan trọng ở đây là tùy thuộc vào tình huống, khối lượng dữ liệu, số lượng người dùng đồng thời, v.v., bạn có thể gặp phải một số giới hạn nhất định. Ví dụ: đến giới hạn của card mạng, giới hạn của ổ cứng hoặc giới hạn khả năng của bộ xử lý. Đây là điều quan trọng mà bạn phải hiểu. Trong các tình huống khác nhau, bạn gặp phải những giới hạn nhất định. Và bạn cần phải hiểu những con số khi bạn đánh chúng.
Có phải chúng ta đang nói về việc đo lường hiệu suất trong một môi trường thử nghiệm đặc biệt? Tức là đây không phải là sản xuất?
Có, đây không phải là sản xuất, đây là môi trường thử nghiệm, luôn giống nhau để bạn có thể so sánh với các phép đo trước đó.
Đã hiểu, cảm ơn!
Nếu không có câu hỏi nào, tôi nghĩ chúng ta có thể kết thúc. Cảm ơn!
Nguồn: www.habr.com