Chúng tôi đã phát triển DevOps tốt nhất có thể. Chúng tôi có 8 người và Vasya là người tuyệt vời nhất trong Windows. Đột nhiên Vasya rời đi, và tôi có nhiệm vụ khởi động một dự án mới do bộ phận phát triển Windows cung cấp. Khi tôi vứt toàn bộ kho phát triển Windows lên bàn, tôi nhận ra rằng tình huống này thật khó khăn...
Đây là cách câu chuyện bắt đầu Alexandra Sinchinova trên . Khi chuyên gia hàng đầu về Windows rời công ty, Alexander băn khoăn không biết phải làm gì bây giờ. Tất nhiên là chuyển sang Linux! Alexander sẽ cho bạn biết cách anh ấy đã tạo ra tiền lệ và chuyển giao một phần quá trình phát triển Windows sang Linux bằng cách sử dụng ví dụ về một dự án đã hoàn thành cho 100 người dùng cuối.
Làm cách nào để phân phối dự án tới RPM một cách dễ dàng và dễ dàng bằng cách sử dụng lõi TFS, Puppet, Linux .NET? Làm cách nào để hỗ trợ tạo phiên bản cho cơ sở dữ liệu dự án nếu nhóm phát triển lần đầu tiên nghe thấy từ Postgres và Flyway và thời hạn là ngày mốt? Làm cách nào để tích hợp với Docker? Làm thế nào để thúc đẩy các nhà phát triển .NET từ bỏ Windows và sinh tố để chuyển sang Puppet và Linux? Làm thế nào để giải quyết xung đột ý thức hệ nếu không có sức mạnh, mong muốn cũng như nguồn lực để duy trì Windows trong sản xuất? Về điều này, cũng như về Triển khai Web, thử nghiệm, CI, về thực tiễn sử dụng TFS trong các dự án hiện có, và tất nhiên, về những chiếc nạng bị hỏng và các giải pháp hoạt động, trong bản ghi báo cáo của Alexander.
Vì vậy, Vasya đã rời đi, nhiệm vụ giao cho tôi, các nhà phát triển đang sốt ruột chờ đợi với những chiếc chĩa ba. Cuối cùng khi tôi nhận ra rằng không thể trả lại Vasya, tôi bắt tay vào công việc. Để bắt đầu, tôi đã đánh giá tỷ lệ phần trăm máy ảo Win trong nhóm của chúng tôi. Tỷ số không nghiêng về Windows.
Vì chúng tôi đang tích cực phát triển DevOps nên tôi nhận ra rằng cần phải thay đổi điều gì đó trong cách tiếp cận phân phối một ứng dụng mới. Chỉ có một giải pháp - nếu có thể, hãy chuyển mọi thứ sang Linux. Google đã giúp tôi - lúc đó .Net đã được chuyển sang Linux và tôi nhận ra rằng đây chính là giải pháp!
Tại sao lõi .NET kết hợp với Linux?
Có nhiều lý do cho việc này. Giữa “trả tiền” và “không trả tiền”, đa số sẽ chọn điều thứ hai - giống như tôi. Giấy phép cho MSDB có giá khoảng 1 USD; việc duy trì một nhóm máy ảo Windows tốn hàng trăm USD. Đối với một công ty lớn, đây là một khoản chi phí lớn. Đó là lý do tại sao tiết kiệm - lý do đầu tiên. Không phải là quan trọng nhất, nhưng là một trong những điều quan trọng.
Máy ảo Windows chiếm nhiều tài nguyên hơn người anh em Linux của chúng - chúng nặng. Với quy mô của công ty lớn, chúng tôi đã chọn Linux.
Hệ thống được tích hợp đơn giản vào CI hiện có. Chúng tôi tự coi mình là DevOps tiến bộ, chúng tôi sử dụng Bamboo, Jenkins và GitLab CI, vì vậy hầu hết công việc của chúng tôi đều chạy trên Linux.
Lý do cuối cùng là đi kèm thuận tiện. Chúng tôi cần hạ thấp rào cản gia nhập đối với “người hộ tống”—những người hiểu rõ phần kỹ thuật, đảm bảo dịch vụ không bị gián đoạn và duy trì các dịch vụ từ tuyến thứ hai. Họ đã quen thuộc với hệ điều hành Linux nên việc hiểu, hỗ trợ và bảo trì một sản phẩm mới sẽ dễ dàng hơn nhiều so với việc dành thêm nguồn lực để hiểu chức năng tương tự của phần mềm dành cho nền tảng Windows.
Yêu cầu
Đầu tiên và quan trọng nhất - sự tiện lợi của giải pháp mới cho các nhà phát triển. Không phải tất cả họ đều sẵn sàng thay đổi, đặc biệt là sau khi Linux được nói ra. Các nhà phát triển muốn Visual Studio, TFS yêu thích của họ có tính năng tự động kiểm tra cho các tổ hợp và sinh tố. Việc giao hàng đến nơi sản xuất diễn ra như thế nào không quan trọng đối với họ. Vì vậy, chúng tôi quyết định không thay đổi quy trình thông thường và giữ nguyên mọi thứ để phát triển Windows.
Dự án mới cần thiết tích hợp vào CI hiện có. Đường ray đã có sẵn và tất cả công việc phải được thực hiện có tính đến các thông số của hệ thống quản lý cấu hình, các tiêu chuẩn phân phối được chấp nhận và hệ thống giám sát.
Dễ dàng hỗ trợ và vận hành, như một điều kiện cho ngưỡng đầu vào tối thiểu cho tất cả những người mới tham gia từ các bộ phận khác nhau và bộ phận hỗ trợ.
Hạn chót - hôm qua.
Nhóm phát triển chiến thắng
Lúc đó nhóm Windows đang làm việc với ai?
Bây giờ tôi có thể tự tin nói rằng IdentityServer4 là một giải pháp thay thế miễn phí thú vị cho ADFS với các khả năng tương tự hoặc những gì Lõi khung thực thể - thiên đường dành cho nhà phát triển, nơi bạn không cần phải bận tâm đến việc viết các tập lệnh SQL mà có thể mô tả các truy vấn trong cơ sở dữ liệu theo thuật ngữ OOP. Nhưng sau đó, trong cuộc thảo luận về kế hoạch hành động, tôi nhìn đống này như thể nó là chữ hình nêm của người Sumer, chỉ nhận ra PostgreSQL và Git.
Vào thời điểm đó chúng tôi đang tích cực sử dụng Múa rối như một hệ thống quản lý cấu hình. Trong hầu hết các dự án của chúng tôi, chúng tôi đã sử dụng CI GitLab, Dây cao su, các dịch vụ tải cao cân bằng sử dụng HAProxy theo dõi mọi thứ với Zabbix, dây chằng grafana и Prometheus, Jaeger, và tất cả những thứ này đang quay trên những mảnh sắt HP c ESXi trên VMware. Mọi người đều biết nó - một tác phẩm kinh điển của thể loại này.
Hãy cùng xem xét và cố gắng hiểu điều gì đã xảy ra trước khi chúng ta bắt đầu tất cả những biện pháp can thiệp này.
Chuyện gì đã xảy ra thế
TFS là một hệ thống khá mạnh, không chỉ cung cấp mã từ nhà phát triển đến máy sản xuất cuối cùng mà còn có một bộ tích hợp rất linh hoạt với các dịch vụ khác nhau - để cung cấp CI ở cấp độ đa nền tảng.
Trước đây, đây là những cửa sổ kiên cố. TFS đã sử dụng một số tác nhân Build được sử dụng để tập hợp nhiều dự án. Mỗi tổng đài viên có 3-4 công nhân để thực hiện song song các nhiệm vụ và tối ưu hóa quy trình. Sau đó, theo kế hoạch phát hành, TFS đã phân phối Bản dựng mới ra mắt cho máy chủ ứng dụng Windows.
Chúng tôi muốn đạt được điều gì?
Chúng tôi sử dụng TFS để phân phối và phát triển cũng như chạy ứng dụng trên máy chủ Ứng dụng Linux và có một số loại phép thuật giữa chúng. Cái này Hộp Magic và còn muối của công việc phía trước. Trước khi tách nó ra, tôi sẽ bước sang một bên và nói vài lời về ứng dụng.
Dự án
Ứng dụng này cung cấp chức năng xử lý thẻ trả trước.
Khách hàng
Có hai loại người dùng. Đầu tiên có được quyền truy cập bằng cách đăng nhập bằng chứng chỉ SSL SHA-2. bạn thứ hai có quyền truy cập bằng thông tin đăng nhập và mật khẩu.
HAProxy
Sau đó, yêu cầu của khách hàng được chuyển đến HAProxy, giải quyết được các vấn đề sau:
- ủy quyền chính;
- Chấm dứt SSL;
- điều chỉnh các yêu cầu HTTP;
- yêu cầu phát sóng.
Chứng chỉ ứng dụng khách đã được xác minh dọc theo chuỗi. Chúng tôi - ủy quyền và chúng tôi có đủ khả năng chi trả cho việc này vì chính chúng tôi cấp chứng chỉ cho khách hàng sử dụng dịch vụ.
Hãy chú ý đến điểm thứ ba, chúng ta sẽ quay lại nó sau một chút.
Backend
Họ đã lên kế hoạch tạo phần phụ trợ trên Linux. Phần phụ trợ tương tác với cơ sở dữ liệu, tải danh sách đặc quyền cần thiết và sau đó, tùy thuộc vào đặc quyền mà người dùng được ủy quyền có, cung cấp quyền truy cập để ký các tài liệu tài chính và gửi chúng để thực thi hoặc tạo một số loại báo cáo.
Tiết kiệm với HAProxy
Ngoài hai bối cảnh mà mỗi khách hàng điều hướng, còn có một bối cảnh nhận dạng. IdentityServer4 chỉ cho phép bạn đăng nhập, đây là một công cụ tương tự miễn phí và mạnh mẽ dành cho ADFS - Dịch vụ liên kết Active Directory.
Yêu cầu nhận dạng đã được xử lý theo một số bước. Bước đầu tiên - khách hàng đã vào phần phụ trợ, đã liên lạc với máy chủ này và kiểm tra sự hiện diện của mã thông báo cho máy khách. Nếu không tìm thấy, yêu cầu sẽ được trả về bối cảnh mà nó đến, nhưng với một chuyển hướng và với chuyển hướng đó, nó sẽ chuyển sang danh tính.
Bước thứ hai - yêu cầu đã được nhận đến trang ủy quyền trong IdentityServer, nơi khách hàng đã đăng ký và mã thông báo được chờ đợi từ lâu đó đã xuất hiện trong cơ sở dữ liệu IdentityServer.
Bước thứ ba - khách hàng đã được chuyển hướng trở lại vào bối cảnh mà nó xuất hiện.
IdentityServer4 có một tính năng: nó trả về phản hồi cho yêu cầu trả lại qua HTTP. Cho dù chúng tôi có gặp khó khăn đến mức nào trong việc thiết lập máy chủ, cho dù chúng tôi đã tìm hiểu kỹ về tài liệu đến mức nào, mỗi lần chúng tôi nhận được yêu cầu ban đầu của khách hàng có URL đến qua HTTPS và IdentityServer đều trả về cùng một ngữ cảnh nhưng với HTTP. Chúng tôi đã bị sốc! Và chúng tôi đã chuyển tất cả những điều này thông qua bối cảnh nhận dạng sang HAProxy và trong tiêu đề, chúng tôi phải sửa đổi giao thức HTTP thành HTTPS.
Cải tiến là gì và bạn đã lưu ở đâu?
Chúng tôi đã tiết kiệm tiền bằng cách sử dụng giải pháp miễn phí để ủy quyền cho một nhóm người dùng, tài nguyên, vì chúng tôi không đặt IdentityServer4 làm một nút riêng biệt trong một phân đoạn riêng biệt mà sử dụng nó cùng với phần phụ trợ trên cùng một máy chủ nơi phần phụ trợ của ứng dụng chạy .
Nó nên hoạt động như thế nào
Vì vậy, như tôi đã hứa - Chiếc hộp ma thuật. Chúng tôi đã hiểu rằng chúng tôi được đảm bảo sẽ hướng tới Linux. Hãy xây dựng các nhiệm vụ cụ thể cần có giải pháp.
Con rối hiện hình. Để cung cấp và quản lý cấu hình dịch vụ cũng như ứng dụng, cần phải viết ra các công thức nấu ăn thú vị. Một cuộn bút chì hùng hồn cho thấy nó được thực hiện nhanh chóng và hiệu quả như thế nào.
Phương thức vận chuyển. Tiêu chuẩn là RPM. Mọi người đều hiểu rằng trong Linux bạn không thể làm gì nếu không có nó, nhưng bản thân dự án, sau khi lắp ráp, là một tập hợp các tệp DLL có thể thực thi được. Có khoảng 150 người trong số họ, dự án khá khó khăn. Giải pháp hài hòa duy nhất là đóng gói tệp nhị phân này thành RPM và triển khai ứng dụng từ nó.
Phiên bản. Chúng tôi phải phát hành rất thường xuyên và phải quyết định cách đặt tên gói. Đây là câu hỏi về mức độ tích hợp với TFS. Chúng tôi đã có một tác nhân xây dựng trên Linux. Khi TFS gửi một tác vụ tới một trình xử lý - nhân viên - tới tác nhân Build, nó cũng chuyển cho nó một loạt các biến kết thúc trong môi trường của quy trình xử lý. Các biến môi trường này chứa Tên bản dựng, tên phiên bản và các biến khác. Đọc thêm về điều này trong phần “Xây dựng gói RPM”.
Thiết lập TFS bắt đầu thiết lập Pipeline. Trước đây, chúng tôi đã thu thập tất cả các dự án Windows trên các tác nhân Windows, nhưng bây giờ một tác nhân Linux xuất hiện - một tác nhân Build, cần được đưa vào nhóm xây dựng, được bổ sung thêm một số tạo phẩm và cho biết loại dự án nào sẽ được xây dựng trên tác nhân Build này và bằng cách nào đó sửa đổi Pipeline.
Máy chủ nhận dạng. ADFS không phải là cách của chúng tôi, chúng tôi hướng tới Nguồn mở.
Chúng ta hãy đi qua các thành phần.
Hộp Magic
Bao gồm bốn phần.
Đại lý xây dựng Linux. Linux, bởi vì chúng tôi xây dựng cho nó - nó rất hợp lý. Phần này được thực hiện trong ba bước.
- Cấu hình công nhân và không đơn độc, vì công việc được phân phối trong dự án đã được mong đợi.
- Cài đặt .NET Core 1.x. Tại sao lại là 1.x khi 2.0 đã có sẵn trong kho tiêu chuẩn? Bởi vì khi chúng tôi bắt đầu phát triển, phiên bản ổn định là 1.09 và chúng tôi quyết định thực hiện dự án dựa trên nó.
- Git 2.x.
Kho lưu trữ RPM. Các gói RPM cần được lưu trữ ở đâu đó. Giả định rằng chúng tôi sẽ sử dụng cùng một kho lưu trữ RPM của công ty có sẵn cho tất cả các máy chủ Linux. Đó là những gì họ đã làm. Máy chủ kho lưu trữ được cấu hình móc trang web đã tải xuống gói RPM cần thiết từ vị trí được chỉ định. Phiên bản gói đã được tác nhân Build báo cáo tới webhook.
gitlab. Chú ý! GitLab ở đây không phải được sử dụng bởi các nhà phát triển mà bởi bộ phận vận hành để kiểm soát các phiên bản ứng dụng, phiên bản gói, theo dõi trạng thái của tất cả các máy Linux và nó lưu trữ công thức - tất cả các bảng kê khai Puppet.
Múa rối — giải quyết tất cả các vấn đề gây tranh cãi và cung cấp chính xác cấu hình mà chúng tôi muốn từ Gitlab.
Chúng tôi bắt đầu lặn. Việc phân phối DLL tới RPM hoạt động như thế nào?
Phân phối DDL tới RPM
Giả sử chúng ta có một ngôi sao nhạc rock phát triển .NET. Nó sử dụng Visual Studio và tạo một nhánh phát hành. Sau đó, nó tải nó lên Git và Git ở đây là một thực thể TFS, tức là nó là kho ứng dụng mà nhà phát triển làm việc.
Sau đó TFS thấy rằng một cam kết mới đã đến. Ứng dụng nào? Trong cài đặt TFS có nhãn cho biết tác nhân Xây dựng cụ thể có những tài nguyên nào. Trong trường hợp này, anh ấy thấy rằng chúng tôi đang xây dựng một dự án .NET Core và chọn tác nhân Linux Build từ nhóm.
Tác nhân Build nhận các nguồn và tải xuống các thông tin cần thiết phụ thuộc từ kho lưu trữ .NET, npm, v.v. và sau khi xây dựng ứng dụng cũng như gói tiếp theo, hãy gửi gói RPM đến kho lưu trữ RPM.
Mặt khác, điều sau đây xảy ra. Kỹ sư của bộ phận vận hành trực tiếp tham gia vào việc triển khai dự án: anh ta thay đổi các phiên bản của gói trong Hiera trong kho lưu trữ công thức ứng dụng, sau đó Puppet kích hoạt yum, tìm nạp gói mới từ kho lưu trữ và phiên bản mới của ứng dụng đã sẵn sàng để sử dụng.
Mọi thứ đều đơn giản về mặt ngôn từ, nhưng điều gì xảy ra bên trong chính tác nhân Build?
Đóng gói DLL RPM
Đã nhận nguồn dự án và nhiệm vụ xây dựng từ TFS. Xây dựng đại lý bắt đầu xây dựng dự án từ các nguồn. Dự án lắp ráp có sẵn dưới dạng một bộ tập tin DLL, được đóng gói trong kho lưu trữ zip để giảm tải cho hệ thống tệp.
Kho lưu trữ ZIP bị vứt đi vào thư mục xây dựng gói RPM. Tiếp theo, tập lệnh Bash khởi tạo các biến môi trường, tìm phiên bản Build, phiên bản dự án, đường dẫn đến thư mục bản dựng và chạy RPM-build. Sau khi quá trình xây dựng hoàn tất, gói sẽ được xuất bản lên kho lưu trữ cục bộ, được đặt trên tác nhân Build.
Tiếp theo, từ tác nhân Build đến máy chủ trong kho RPM Yêu cầu JSON được gửi cho biết tên của phiên bản và bản dựng. Webhook, mà tôi đã nói trước đó, tải xuống gói này từ kho lưu trữ cục bộ trên tác nhân Build và cung cấp bản hợp ngữ mới để cài đặt.
Tại sao lại có sơ đồ phân phối gói cụ thể này tới kho lưu trữ RPM? Tại sao tôi không thể gửi ngay gói đã lắp ráp đến kho lưu trữ? Thực tế đây là điều kiện để đảm bảo an toàn. Kịch bản này hạn chế khả năng những người không được phép tải gói RPM lên máy chủ mà tất cả các máy Linux đều có thể truy cập được.
Phiên bản cơ sở dữ liệu
Khi tham khảo ý kiến của nhóm phát triển, hóa ra những người này đã gần gũi hơn với MS SQL, nhưng trong hầu hết các dự án không phải Windows, chúng tôi đã sử dụng hết khả năng của mình PostgreSQL. Vì chúng tôi đã quyết định từ bỏ mọi thứ đã thanh toán nên chúng tôi cũng bắt đầu sử dụng PostgreSQL ở đây.
Trong phần này, tôi muốn cho bạn biết cách chúng tôi tạo phiên bản cho cơ sở dữ liệu và cách chúng tôi chọn giữa Flyway và Entity Framework Core. Hãy nhìn vào ưu và nhược điểm của họ.
Nhược điểm
Đường bay chỉ đi một chiều, chúng ta chúng ta không thể quay lại - đây là một bất lợi đáng kể. Bạn có thể so sánh nó với Entity Framework Core theo những cách khác - về mặt thuận tiện cho nhà phát triển. Bạn hãy nhớ rằng chúng tôi đã đặt vấn đề này lên hàng đầu và tiêu chí chính là không thay đổi bất cứ điều gì đối với việc phát triển Windows.
Đối với Flyway chúng tôi cần có một số loại giấy góiđể các chàng đừng viết truy vấn SQL. Họ tiến gần hơn nhiều đến việc hoạt động theo thuật ngữ OOP. Chúng tôi đã viết hướng dẫn cách làm việc với các đối tượng cơ sở dữ liệu, tạo một truy vấn SQL và thực thi nó. Phiên bản mới của cơ sở dữ liệu đã sẵn sàng, đã được thử nghiệm - mọi thứ đều ổn, mọi thứ đều hoạt động.
Entity Framework Core có một điểm trừ - khi tải nặng xây dựng các truy vấn SQL dưới mức tối ưuvà sự sụt giảm trong cơ sở dữ liệu có thể là đáng kể. Nhưng vì chúng tôi không có dịch vụ tải cao nên chúng tôi không tính tải theo hàng trăm RPS, nên chúng tôi chấp nhận những rủi ro này và giao vấn đề cho chúng tôi trong tương lai.
Ưu điểm
Lõi khung thực thể hoạt động vượt trội và dễ phát triển, và đường bay Dễ dàng tích hợp vào CI hiện có. Nhưng chúng tôi làm cho nó thuận tiện cho các nhà phát triển :)
Thủ tục cuộn lên
Puppet nhận thấy sắp có sự thay đổi trong phiên bản gói, bao gồm cả phiên bản chịu trách nhiệm di chuyển. Đầu tiên, nó cài đặt một gói chứa các tập lệnh di chuyển và chức năng liên quan đến cơ sở dữ liệu. Sau đó, ứng dụng hoạt động với cơ sở dữ liệu sẽ được khởi động lại. Tiếp theo là cài đặt các thành phần còn lại. Thứ tự cài đặt các gói và khởi chạy ứng dụng được mô tả trong bản kê khai Puppet.
Các ứng dụng sử dụng dữ liệu nhạy cảm, chẳng hạn như mã thông báo, mật khẩu cơ sở dữ liệu, tất cả những thứ này được đưa vào cấu hình từ Puppet master, nơi chúng được lưu trữ ở dạng mã hóa.
vấn đề về TFS
Sau khi chúng tôi quyết định và nhận ra rằng mọi thứ đang thực sự hiệu quả với chúng tôi, tôi quyết định xem xét những gì đang diễn ra với các tổ hợp trong TFS nói chung đối với bộ phận phát triển Win trong các dự án khác - cho dù chúng tôi có đang xây dựng/phát hành nhanh chóng hay không, và đã phát hiện ra những vấn đề nghiêm trọng về tốc độ.
Một trong những dự án chính phải mất 12-15 phút để lắp ráp - đó là một thời gian dài, bạn không thể sống như vậy được. Một phân tích nhanh cho thấy sự sụt giảm nghiêm trọng trong I/O và điều này xảy ra trên mảng.
Sau khi phân tích từng thành phần, tôi xác định được ba trọng tâm. Đầu tiên - "Phần mềm diệt virus Kaspersky", quét các nguồn trên tất cả các tác nhân Windows Build. Thứ hai - Windows Người lập chỉ mục. Nó không bị vô hiệu hóa và mọi thứ đều được lập chỉ mục theo thời gian thực trên các tác nhân Xây dựng trong quá trình triển khai.
Ngày thứ ba - Npm cài đặt. Hóa ra là trong hầu hết các Đường ống, chúng tôi đã sử dụng chính xác kịch bản này. Tại sao anh ấy lại xấu? Quy trình cài đặt Npm được chạy khi cây phụ thuộc được hình thành trong gói-lock.json, nơi ghi lại phiên bản của các gói sẽ được sử dụng để xây dựng dự án. Nhược điểm là Npm install luôn lấy các phiên bản mới nhất của gói từ Internet và việc này mất rất nhiều thời gian trong trường hợp một dự án lớn.
Các nhà phát triển đôi khi thử nghiệm trên máy cục bộ để kiểm tra cách hoạt động của một phần cụ thể hoặc toàn bộ dự án. Đôi khi hóa ra mọi thứ đều ổn ở địa phương, nhưng họ đã lắp ráp, tung ra và không có tác dụng gì. Chúng tôi bắt đầu tìm ra vấn đề là gì - vâng, các phiên bản khác nhau của gói có phần phụ thuộc.
phán quyết
- Các nguồn trong trường hợp ngoại lệ AV.
- Vô hiệu hóa lập chỉ mục.
- Đi đến npm ci.
Ưu điểm của npm ci là chúng ta Chúng tôi thu thập cây phụ thuộc một lầnvà chúng tôi có cơ hội cung cấp cho nhà phát triển danh sách các gói hiện tại, nhờ đó anh ấy có thể thử nghiệm tại địa phương bao nhiêu tùy thích. Cái này tiết kiệm thời gian các nhà phát triển viết mã.
Cấu hình
Bây giờ một chút về cấu hình kho lưu trữ. Trong lịch sử chúng ta sử dụng Nexus để quản lý kho lưu trữ, bao gồm REPO nội bộ. Kho lưu trữ nội bộ này chứa tất cả các thành phần mà chúng tôi sử dụng cho mục đích nội bộ, chẳng hạn như giám sát tự viết.
Chúng tôi cũng dùng NuGet, vì nó có bộ nhớ đệm tốt hơn so với các trình quản lý gói khác.
Kết quả
Sau khi chúng tôi tối ưu hóa Tác nhân xây dựng, thời gian xây dựng trung bình đã giảm từ 12 phút xuống còn 7.
Nếu chúng tôi tính tất cả các máy mà lẽ ra chúng tôi có thể sử dụng cho Windows nhưng lại chuyển sang Linux trong dự án này, chúng tôi đã tiết kiệm được khoảng 10 USD. Và đó chỉ là về giấy phép và hơn thế nữa nếu chúng tôi tính đến nội dung.
Kế hoạch
Trong quý tiếp theo, chúng tôi đã lên kế hoạch tối ưu hóa việc phân phối mã.
Chuyển sang hình ảnh Docker dựng sẵn. TFS là một điều thú vị với nhiều plugin cho phép bạn tích hợp vào Pipeline, bao gồm cả việc lắp ráp hình ảnh Docker dựa trên trình kích hoạt. Chúng tôi muốn kích hoạt điều này cho cùng một điều gói-lock.json. Nếu thành phần của các thành phần được sử dụng để xây dựng dự án thay đổi theo cách nào đó, chúng tôi sẽ xây dựng hình ảnh Docker mới. Sau đó nó được sử dụng để triển khai vùng chứa với ứng dụng đã được lắp ráp. Hiện tại thì không, nhưng chúng tôi đang có kế hoạch chuyển sang kiến trúc vi dịch vụ trong Kubernetes, kiến trúc này đang tích cực phát triển trong công ty chúng tôi và đã phục vụ các giải pháp sản xuất trong một thời gian dài.
Tóm tắt thông tin
Tôi khuyến khích mọi người vứt Windows đi nhưng không phải vì tôi không biết nấu nó. Lý do là hầu hết các giải pháp Opensource đều ngăn xếp Linux. Bạn có ổn không tiết kiệm tài nguyên. Theo tôi, tương lai thuộc về các giải pháp Open Source trên Linux với cộng đồng hùng mạnh.
Hồ sơ diễn giả của Alexander Sinchinov .
là hội nghị về sự tích hợp các quy trình phát triển, thử nghiệm và vận hành dành cho các chuyên gia của các chuyên gia. Đó là lý do tại sao dự án mà Alexander nói đến? đã được triển khai và hoạt động, và vào ngày biểu diễn đã có hai bản phát hành thành công. TRÊN Vào ngày 27 và 28 tháng XNUMX sẽ còn có nhiều trường hợp tương tự hơn nữa từ các học viên. Bạn vẫn có thể nhảy lên toa xe cuối cùng và hoặc dành thời gian của bạn vé. Gặp chúng tôi ở Skolkovo!
Nguồn: www.habr.com