Có thể chấp nhận triển khai ứng dụng web để sản xuất trực tiếp từ SVN

Câu hỏi

Có một lý do chính đáng KHÔNG sử dụng SVN cho các triển khai sản xuất, hay đây chỉ là một trường hợp sở thích cá nhân và không có trường hợp thực sự chống lại SVN?

Lý lịch

Nơi làm việc của tôi có văn hóa gắn thẻ phát hành trong SVN và sau đó triển khai các bản phát hành đó trực tiếp đến các máy chủ web khác nhau bằng cách sử dụng svn cohoặc svn switchbao gồm trực tiếp vào sản xuất.

Cá nhân tôi có một vấn đề với điều này vì tôi tin rằng nếu không sử dụng tập lệnh xây dựng và triển khai hoặc một số hình thức hoặc triển khai tự động, bạn sẽ mất các cài đặt môi trường tích hợp vì chúng không có giấy tờ. Tuy nhiên, nhiều hơn thế tôi có một cảm giác đặc biệt rằng có thể có một mối nguy hiểm tiềm ẩn khi làm điều đó đã bị bỏ qua, một cái gì đó vẫn chưa nuôi cái đầu xấu xí của nó.

Tôi đã đưa ra mối quan tâm của mình với các nhân viên hoạt động, những người chịu trách nhiệm triển khai mã cho các môi trường khác nhau của chúng tôi (dàn dựng, tiền sản xuất, sản xuất), v.v.

Biên tập:

Ý tôi là gì về xây dựng và triển khai:

Ví dụ: nếu nhà phát triển yêu cầu cài đặt web.config được thêm cho một môi trường cụ thể. Web.config thường không được giữ trong svn và vì vậy các tệp này được cập nhật thủ công mà không có bất kỳ dạng tập lệnh xây dựng tự động nào. Vì vậy, nếu họ bị mất hoặc OPS quên thêm một trường vào web.config để phát hành thì bạn có vấn đề.

Tập lệnh xây dựng sử dụng XMLPoke để tự động tạo web.config phù hợp với một môi trường cụ thể là lý tưởng ở chỗ bạn có tập lệnh có thể phiên bản, ghi lại tất cả các thay đổi cần thiết cho từng môi trường của bạn.

Phương pháp xây dựng và triển khai hiện tại

Đối với dự án đang được đề cập, nhà phát triển xây dựng bản phát hành theo cách thủ công, các dự án khác có bước xây dựng tự động với NANT hoặc MSBuild đều ổn.

Di chuyển cơ sở dữ liệu cho hầu hết các dự án là thông qua các tập lệnh DB hoặc tập lệnh di chuyển (Migrator.NET) hoặc Gói CMS.

CI thường được Team City thực hiện trên cơ sở mỗi lần đăng ký, chúng tôi có quy trình xem xét mã rằng tất cả các vé được thực hiện trong các chi nhánh và sau đó được xem xét để xác thực và tính chính xác / chất lượng trước khi kiểm tra vào thân cây (hoạt động tốt).

Tuy nhiên, việc triển khai mã thực tế luôn diễn ra khá nhiều thông qua SVN, thông qua việc kiểm tra một bản phát hành được gắn thẻ hoặc nói chung là SVN Switch. Đây là một điều gì đó kỳ quặc với tôi rằng chúng tôi đang sử dụng kho lưu trữ của chúng tôi như một phần của quy trình triển khai.

Cấu hình thường không thay đổi rất thường xuyên, điều duy nhất sẽ có trong các tệp cấu hình là thông tin cụ thể về môi trường. Mọi thứ khác đều nằm trong db.

Đừng hiểu sai ý tôi, nó hoạt động tốt. Tuy nhiên tôi muốn thử và thúc đẩy xây dựng và triển khai tự động. Tôi đã sử dụng điều này với Rails và Capistrano và cho các dự án cá nhân sử dụng Cygwin, Nant và SSH.

Quan trọng hơn, tôi sẽ cần các đối số hợp lệ rất cụ thể để khiến các đồng nghiệp của mình thay đổi sang sử dụng bản dựng và triển khai Tự động.

Hoặc KHÔNG có đối số hợp lệ thực sự nào chống lại việc sử dụng SVN cụ thể để triển khai vào sản xuất?

Từ kinh nghiệm của tôi, có cả ưu điểm và nhược điểm:

Ưu điểm:

• Đôi khi bạn thực hiện các sửa lỗi nóng khẩn cấp trên máy chủ sản xuất, sau đó bạn có thể kiểm tra lại chúng trực tiếp từ đó. (Mặc dù về mặt lý thuyết, vì lý do bảo mật, luôn luôn nên sử dụng quyền truy cập chỉ đọc vào repo từ máy chủ sản xuất.)

• Đơn giản: bạn cung cấp nhanh chóng, mặc dù như những người khác đã đề cập ở đây, chuyển sang sơ đồ cập nhật tập lệnh có thể dễ dàng như vậy.

Nhược điểm:

• Hệ thống của bạn có thể trở nên không ổn định trong quá trình svn upcập nhật DB và của bạn . Đối với một trang web có lưu lượng truy cập cao, điều này có nghĩa là một số người dùng sẽ nhấn các thông báo lỗi, các trang bị hỏng hoặc các trang trống tốt nhất. Chà, đó là những gì chúng ta rất thường thấy trên các dịch vụ xã hội khác nhau. Tuy nhiên, một dịch vụ tốt thực hiện "nguyên tử" theo nghĩa là nó sẽ đưa hệ thống vào chế độ bảo trì trong suốt thời gian cập nhật. ( Bạn đã phá vỡ reddit! )

• Xung đột: giải quyết xung đột đột ngột trên máy chủ sản xuất là một ý tưởng tồi tệ: một lần nữa, dịch vụ trở nên không ổn định trong khi bạn đang sửa nó.

• Các tệp không liên quan trên máy chủ sản xuất có thể thuộc hoặc không thuộc về bạn, mặc dù tất nhiên bạn có thể tránh nó bằng cách kiểm tra cây con bên phải trong repo.

• Bảo mật: ai đó có quyền truy cập vào máy chủ sản xuất của bạn, hợp pháp hay không, cũng có quyền truy cập vào kho của bạn, có thể cả các sản phẩm khác, và cũng có thể có quyền truy cập ghi! Nhìn chung, việc mở máy chủ SVN nội bộ của bạn ra thế giới bên ngoài là một ý tưởng tồi. Kho lưu trữ nguồn của bạn nên ở phía sau tường lửa của công ty.

• Dù sao cũng sẽ có các kịch bản cập nhật, ví dụ như để cập nhật cấu trúc DB, quản lý các cronjobs, v.v. vậy tại sao không có một tập lệnh nào làm tất cả? - tức là kéo bản phát hành đóng gói sẵn mới nhất, chuyển sang chế độ bảo trì, cập nhật nguồn, chạy các tập lệnh dành riêng cho phát hành, v.v.

Chỉnh sửa: đối với những người vẫn sử dụng lược đồ SVN, đừng quên điều này trong cấu hình apache của bạn:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

Tôi đã thiết lập một máy chủ CI trong công việc của mình để tự động tạo trình cài đặt của chúng tôi giả sử rằng các bài kiểm tra đơn vị vượt qua thành công. Mất khoảng một ngày làm việc và nó đã giúp tôi tiết kiệm nhiều hơn thế kể từ khi tôi thiết lập nó.

Nếu có bất kỳ quy trình thủ công nào trong việc định cấu hình trang web phát hành / cài đặt / sản xuất của bạn thì bạn sẽ luôn tiết kiệm thời gian cho bản thân và công ty. Điều này phù hợp với bạn vì từ câu hỏi của bạn, có vẻ như có các bước cấu hình thủ công trong quy trình thiết lập của bạn.

Để tham khảo, hãy xem chính Joel nói về cách một quy trình xây dựng một lần nhấp giúp bạn tiết kiệm trong ngắn hạn và trung hạn.

Đảm bảo rằng bạn có các điều khiển đăng ký thích hợp trên SVN. Ví dụ, hãy xem xét điều này -

• Các tính năng được kiểm tra để phát hành
• Mã được triển khai để dàn dựng, QA thực hiện công việc của mình
• Lỗi đã được sửa, một vòng thử nghiệm khác (tuy nhiên nó hoạt động trong nhóm của bạn)
• Ditto cho tiền sản xuất
• Triển khai sản xuất

Nếu ai đó vô tình thực hiện đăng ký sau giai đoạn tiền sản xuất, có nguy cơ phá vỡ một cái gì đó. Nếu điều này được kiểm soát - như không có kiểm tra nào được cho phép trong quá trình tiền sản xuất ngoại trừ sửa lỗi - tôi không thấy bất kỳ rủi ro nào.

Cập nhật: Bạn có một vấn đề đang chờ xảy ra nếu bạn không kiểm tra các tệp cấu hình của mình. Tôi thực sự không thể đưa ra bất kỳ lời khuyên nào cho việc này ngoài việc "làm ơn và nhanh chóng!"

Có vẻ như ok miễn là không có gì bên ngoài kho lưu trữ. Nguyên vẹn, tôi tin rằng người ta không nên đầu tư thời gian vào các công cụ triển khai trong vài tháng đầu tiên của dự án. Nguyên nhân sẽ có quá nhiều triển khai, không đủ khách hàng để bị làm phiền về một quy trình phát hành chính thức.

Nhưng một khi dự án khoảng một năm tuổi, nó đáng để xem xét đầu tư vào công cụ triển khai. Lý do đơn giản là

• Doanh nghiệp phát triển để bạn có kế hoạch lưu trữ nó trên nhiều máy chủ
• Có thể có lỗi trên một môi trường cụ thể và bạn không có nơi nào để sao chép lỗi. Không có cách nào dễ dàng để thiết lập nó mà không có quá trình tar-unlar-quên_about_home_for_a_week.
• Một số có khả năng phá vỡ các bản dựng. Ai phá vỡ tòa nhà

Nếu bạn muốn thuyết phục họ, hãy yêu cầu họ thiết lập một máy chủ khác để thử nghiệm nội bộ hoặc QA.