Lý do tốt, đơn giản để có nhiều môi trường


71

Trong suốt sự nghiệp của mình, tôi đã làm việc tại các công ty có một bộ sưu tập các môi trường khác nhau cho các mục đích khác nhau. Chúng tôi luôn có ít nhiều môi trường máy tính để bàn, môi trường thử nghiệm, môi trường QA, môi trường dàn dựng và môi trường sản xuất. Điều này diễn ra cho cả máy chủ / ứng dụng và bất kỳ nguồn dữ liệu nào chúng tôi đang sử dụng.

Khi tôi bắt đầu tại công ty hiện tại, tôi thấy rằng 90% ứng dụng được phát triển trên môi trường máy tính để bàn dựa trên nguồn dữ liệu sản xuất hoặc được phát triển trực tiếp trên máy chủ sản xuất tùy thuộc vào nền tảng. Điều này không đặc biệt đáng ngạc nhiên, vì tôi được thuê một phần để thực hiện các thay đổi để cải thiện cách thức hoạt động của nhóm phát triển, điều này rõ ràng từ quá trình phỏng vấn của tôi. Chúng tôi dần dần bắt đầu thay đổi triết lý và khá sớm, hầu hết các ứng dụng có thể chạy trong môi trường máy tính để bàn, thử nghiệm hoặc sản xuất. Không lâu sau đó, dàn dựng cũng xuất hiện.

Bây giờ hầu hết các nhà phát triển của chúng tôi thấy lợi ích của phương pháp này và bảo vệ nó một cách thận trọng. Tuy nhiên, chúng tôi có một số ứng dụng cũ không bao giờ được di chuyển. Chúng tôi cũng có một số lập trình viên kế thừa nghĩ rằng điều này là một sự lãng phí thời gian. Thật không may, chúng tôi có dịch vụ môi nhưng không bao giờ mua đầy đủ từ ban quản lý. Chúng tôi đã nhận được những gì chúng tôi nghĩ là một cam kết đầu tư đáng kể vào việc này khoảng một năm trước, nhưng không có gì được thực hiện mặc dù kế hoạch đáng kể mà chúng tôi đưa vào. Bây giờ chúng tôi thấy rằng chúng tôi cần ngày càng nhiều môi trường. Chúng tôi cần sự giúp đỡ từ các nhóm quản trị máy chủ / mạng để thiết lập và chúng tôi cần sự tham gia của các bên liên quan kinh doanh để hỗ trợ chu kỳ phát hành. Chúng tôi đang ở một nơi mà một dự án có thể hoạt động những gì các nhà phát triển hợp lý sẽ xem xét "bình thường"

Tôi muốn trình bày một lập luận đầy đủ, nhưng quản lý thực sự không có thời gian và hứng thú để nghe tôi nói cho đến khi có một vấn đề quan trọng. Tôi thực sự không thể nói rõ lợi ích đơn giản vì nó luôn có vẻ như là bản chất thứ hai đối với tôi. Tôi đã tự hỏi nếu có bất kỳ lý do tốt, đơn giản, không thể bác bỏ cho việc tách các môi trường sẽ khiến các nhà quản lý thiếu kinh nghiệm phát triển để hỗ trợ ý tưởng này? . Có bất kỳ tài nguyên / tài liệu tốt về chủ đề này?


1
Câu hỏi tuyệt vời, tôi quan tâm để nghe những gì người khác nói. Tôi không có câu trả lời tốt cho bạn vì các nhà quản lý muốn số cứng và tất cả lợi ích của việc có nhiều môi trường khó đo lường bằng số cứng.
maple_shaft

4
Làm thế nào chưa có một vấn đề quan trọng? Nếu các ứng dụng đang được phát triển trong môi trường sản xuất, thì nó sẽ phổ biến (và phổ biến trong môi trường dev bình thường) cho các lỗi cơ bản để vô hiệu hóa các tính năng, gây ra các điều kiện lỗi và thậm chí làm hỏng toàn bộ ứng dụng. Là ứng dụng không quan trọng đến mức những vấn đề này không phải là thất bại nghiêm trọng?
JGweissman

2
Đây không phải là trường hợp không dẫn đến các vấn đề quan trọng. Đó là một trường hợp của họ không hiểu làm thế nào nó là nguyên nhân của các vấn đề quan trọng. Tôi cho rằng tôi đã không nói nó đủ tốt.
smp7d

1
Chúc tôi có một vận may để bắt đầu một tiền thưởng!
Kris

7
Đối với bất cứ ai quan tâm ... đã hai năm kể từ khi tôi hỏi câu hỏi này và chúng tôi có một môi trường tách biệt rõ ràng. Nó xảy ra vì sự lặp lại. Chúng tôi liên tục nói rằng chúng tôi cần nó và chúng tôi đã mất một số nhân viên chống lại nó và chiến thắng những người khác. Chậm rãi thủy triều quay đầu. Tôi ước có một công thức để có được nó, nhưng tôi đoán văn hóa phải tự nhiên chấp nhận nó.
smp7d

Câu trả lời:


86

Câu trả lời: Tiền

Tôi không quan tâm lý do thực sự là gì. Tiền PHẢI là gốc rễ của tất cả lý luận của bạn, đặc biệt là khi giao dịch với quản lý.

Nếu cả hai chúng tôi ngồi trong một căn phòng trong 2 giờ, chúng tôi có thể đưa ra hàng tá lý do tại sao tốt hơn là có nhiều môi trường.

Đây là vấn đề: Nếu lý do không dựa trên tiền, thì không có vấn đề nào trong số đó .

Lập trình viên không được thuê để thông minh. Họ không được thuê để sáng tạo. Họ được thuê để tăng doanh thu - bằng cách kiếm tiền hoặc tiết kiệm tiền. Nếu bạn không làm một trong những điều đó, tốt hơn hết bạn nên lấy sơ yếu lý lịch của mình.

Khi nhìn vào nó từ quan điểm đó, câu trả lời rất đơn giản:

Chỉ có một môi trường làm tăng thời gian chết của chúng tôi và dẫn đến doanh thu bị mất. Nhiều môi trường cho phép chúng tôi bảo vệ lợi nhuận của mình bằng cách cung cấp cho người dùng của chúng tôi một giao diện đáng tin cậy và đáng tin cậy như công ty của chúng tôi.

Lặp lại nó mỗi ngày.


Có một số ý kiến ​​tuyệt vời dưới đây bổ sung một số giá trị thực sự cho câu trả lời này, vì vậy tôi sẽ đề cập đến chúng:

  • Karl Bielefeldt đã có một điểm tuyệt vời khi ông đề cập rằng phân tích Chi phí / Lợi ích là một yếu tố quan trọng. Một nhà kinh tế có thể coi nó là chi phí cơ hội của việc theo đuổi nhiều môi trường. Mặc dù có thể đáng ngạc nhiên khi nghe, có những kịch bản trong đó nhiều môi trường có thể không phải là câu trả lời! Nếu trang web của công ty bạn là một bổ sung rất nhỏ, thì thời gian chết bất ngờ thực sự có thể là cách kinh doanh hiệu quả hơn về mặt chi phí. Điều này không giống như vị trí bạn đang ở, nhưng nó đáng được đề cập.

  • BlairHippo đã có một điểm tốt ở chỗ bạn nên thoải mái biến nó thành một thảm họa (và nếu bạn mất dữ liệu của mình, thì đúng là như vậy!). Trách nhiệm là một công cụ tuyệt vời để thuyết phục các nhà quản lý, nhưng vẫn vì lý do tương tự - các vụ kiện rất tốn kém. Tránh họ tiết kiệm tiền.


Là một phụ lục, tôi thấy bài viết này là khá tốt. Nó không trực tiếp trả lời câu hỏi của bạn, nhưng cho phép bạn nhận ra cách các lập trình viên được xem để quản lý, từ đó dẫn đến câu trả lời này. Đọc tốt.


12
+1 Đối với tiền là quản lý ngôn ngữ duy nhất hiểu. Nhân tiện, trích dẫn Nó là succint và hoàn hảo.
maple_shaft

7
Câu trả lời chính xác. Chỉ muốn thêm rằng lợi ích phải vượt quá chi phí. Sau một ngưỡng nhất định, việc thêm nhiều môi trường kiểm tra sẽ có giá cao hơn mức tiết kiệm.
Karl Bielefeldt

4
+1 cho bài viết "Đừng tự gọi mình là lập trình viên"
nwahmaet

3
Câu trả lời chính xác. Tôi cũng muốn nói thêm: hãy thoải mái thảm họa một chút. Miễn là bạn phát hành mã chưa được kiểm tra về dữ liệu sản xuất, luôn có khả năng vô tình thu thập dữ liệu nói. Tiền có thể là ngôn ngữ được sử dụng bởi tất cả các nhà quản lý, nhưng Trách nhiệm ít nhất là một phương ngữ phổ biến.
BlairHippo

Có rất nhiều câu trả lời đúng cho câu hỏi này, nhưng đây là câu trả lời hay nhất.
smp7d

18

Điểm duy nhất của sự thất bại

Bằng cách không có môi trường phát triển hoặc dàn dựng, bạn có một Điểm duy nhất cho các ứng dụng cũ. Quản lý sẽ nghe bạn nếu bạn mô tả các ứng dụng cũ trong các điều khoản đó.

Bạn cần có khả năng gửi thông điệp của mình theo byte âm thanh có ý nghĩa với chúng. Lấy " Lập trình viên nói " ra khỏi cuộc thảo luận và thay thế bằng " Quản lý nói ". Cũng giả vờ bạn có một chuyến đi thang máy 30 giây để có được điểm của bạn.

Tôi đã có một tình huống mà ông chủ của tôi là một lính bộ binh. Tôi tiếp tục nói với anh ấy rằng tôi cần các công cụ phần mềm và đào tạo máy tính cho Thủy quân lục chiến của tôi để có năng suất cao hơn. Anh ấy đã không nhận được nó. Cuối cùng tôi cũng đến văn phòng của anh ấy một ngày và nói với anh ấy mọi thứ đã được đưa lên.

Tôi đã nói điều gì đó với tác dụng ... "Nếu tôi đang chiến đấu, tôi sẽ sử dụng gậy, đá và cành cây. Thứ tôi cần là lựu đạn, súng bazooka và súng máy." Anh nhận được tin nhắn.


Haha, cảm ơn vì câu trả lời tốt Tôi đồng ý rằng trực tiếp và tích cực là giải pháp để có được những gì bạn muốn. Tôi chưa bao giờ có một người quản lý hàng hải nhưng mong muốn sử dụng súng bazooka và súng máy trong một cuộc tranh cãi.
Filip

9

Có thực sự quan trọng?

Tôi có thể hiểu mong muốn sử dụng các môi trường riêng biệt. Câu hỏi không rõ ràng là:

Có thực sự quan trọng để di chuyển một hệ thống di sản ?

Tôi nghĩ rằng hầu hết những người có đầu óc kỹ thuật có xu hướng tập trung vào câu hỏi học thuật về cách nào tốt hơn trong học viện. Trong kinh doanh mặc dù tốt nhất không phải lúc nào cũng thắng. Tôi không nói điều này là tiêu cực, hoặc bắt đầu một cuộc chiến rực lửa. Tôi đang nói rõ ràng, hoặc những gì nên rõ ràng đối với những người trong chúng ta đã kinh doanh phần mềm trong một vài năm.

Tất cả các quyết định kinh doanh thường được thực hiện dựa trên chi phí / lợi ích cảm nhận được. Vì vậy, câu hỏi mà doanh nghiệp có thể hỏi là:

Là chi phí của hệ thống bổ sung và đầu tư phát triển trong một ứng dụng cũ có xứng đáng với lợi ích so với việc đưa khoản đầu tư tương tự đó vào một dự án / sản phẩm khác không?

Tôi đã và vẫn thực hiện phân tích lợi ích chi phí thường xuyên để đưa ra các quyết định không chỉ trong việc di chuyển / viết lại phần mềm, mà trong các quyết định hàng ngày, một khách hàng tiềm năng thường tham gia. Tôi đã chuyển qua viết lại / di chuyển phần mềm cũ vì nó bị hạn chế và do đó giá trị.

Môi trường riêng biệt

Các lý do kinh doanh để môi trường riêng biệt.

  • Ít rủi ro hơn trong các bản phát hành và sửa lỗi. Chứng minh bằng số. Đã bao nhiêu lần sản phẩm thất bại và làm mất doanh thu của khách hàng vì một lỗi phát hành / lỗi xấu.
  • Ít rủi ro trong phát triển. Vô tình thổi bay dev db khác với việc vô tình thổi bay db sản xuất
  • Khả năng phân tách rõ ràng vai trò và truy cập tức là. an ninh tốt hơn. giới hạn số lượng ngón tay trong chiếc bánh sản xuất là một điều tốt
  • Khả năng phân tách các môi trường và các thực tiễn và quy trình đi cùng với phong cách phát triển này cho phép xây dựng trong tương lai vào Hệ thống đám mây.
  • Sự phân tách môi trường sẽ tạo ra hiệu quả trong việc tái tạo môi trường có thể hữu ích trong việc lên kế hoạch cũng như nhân rộng.

+1 Để chỉ ra rằng điều quan trọng là phải xem xét chi phí.
sleske

Yêu lý do kinh doanh của bạn để môi trường riêng biệt. Đặc biệt là câu đầu tiên 3. Câu trả lời hay nhất. Cảm ơn.
John Assymptoth

8

Có vẻ như bạn đã có tất cả các đối số "đúng". Thay vào đó, bạn đang trải qua một "cá trích đỏ", nếu bạn muốn. Hoặc, "đuổi theo củ cà rốt"

quản lý thực sự không có thời gian và quan tâm đến việc lắng nghe tôi cho đến khi có một vấn đề quan trọng

Đó là những gì tôi coi là vấn đề thực sự. Theo kinh nghiệm của tôi, nếu một công ty có thực tiễn phát triển dưới mức kém như bạn mô tả. Đó không chỉ đơn giản là vấn đề "chúng tôi không biết gì hơn". Thay vào đó, đây là một bản tổng hợp các khoản nợ kỹ thuật do một nhóm quản lý cấp cao không biết (quan tâm?) Về các vấn đề mà nó đưa ra.

Trong những trường hợp như vậy, một cuộc nói chuyện tốt sẽ không đột nhiên xoay chuyển mọi thứ theo hướng của bạn. Có thể một chấn thương nghiêm trọng (lỗi sản phẩm có thể nhìn thấy đối với khách hàng và trực tiếp gắn liền với các thực tiễn kém), nhưng tôi chắc chắn các kỹ thuật viên hiểu biết lành mạnh trước khi bạn thử điều này.

Đề nghị của tôi là hoặc hút nó lên và lấy mọi thứ cho những gì họ đang có hoặc tìm kiếm một vị trí mới.


7

Có bao nhiêu nhóm người dự định làm việc trên ứng dụng một lúc? Usuaslly Tôi đã thấy một môi trường cho mỗi nhóm người. Đây là Nhà phát triển (họ có môi trường DEV và môi trường Tích hợp DEV - một số người cho rằng không cần thiết 100%, tôi nói nó thay đổi theo dự án), hai môi trường thử nghiệm (một nhóm người thử nghiệm thực hiện thử nghiệm rất chi tiết, nhóm kia thử nghiệm người kiểm tra QA cấp cao - thường là người dùng kinh doanh thực tế, không phải người kiểm tra được đào tạo). Ngoài ra còn có một môi trường kiểm tra Hiệu suất riêng biệt (vì vậy bạn có thể kiểm tra khối lượng dữ liệu khổng lồ, mô phỏng khối lượng người dùng khổng lồ, v.v ... g).

Tại sao tất cả các môi trường? Vì vậy, các nhóm khác nhau có thể kiểm tra các tính năng khác nhau mà không cần giẫm lên các ngón chân của nhau. Nếu các nhà phát triển và người thử nghiệm làm việc trong cùng một môi trường, đó là một cơn ác mộng: một người thử nghiệm có thể mở ra một khiếm khuyết trên một tính năng đang được nhà phát triển thay đổi tích cực mỗi phút. Nếu có hai cấp độ thử nghiệm, họ có thể tập trung vào các hoạt động khác nhau và không lo lắng về việc làm xáo trộn dữ liệu của nhau. Có một môi trường hiệu suất biệt lập cho phép bạn chạy các thử nghiệm có thể treo máy, nhưng nếu nó bị cô lập, sẽ không có người thử nghiệm nào khác bị ảnh hưởng.

Khi quá nhiều người cố gắng làm quá nhiều việc khác nhau trong cùng một môi trường, bạn sẽ mất rất nhiều thời gian vì một nhóm chờ đợi bài kiểm tra của nhóm khác kết thúc để họ có thể chạy thử. Và điều đó làm lãng phí thời gian và lãng phí thời gian có thể dẫn đến lãng phí tiền bạc, điều mà Stargazer712 chỉ ra có thể tạo ra sức mạnh mạnh mẽ nhất.

Một lý do khác (không phổ biến) là dữ liệu: nếu ứng dụng của bạn có dữ liệu cá nhân hoặc dữ liệu thẻ tín dụng nhạy cảm, bạn thường không thể đưa dữ liệu đó vào môi trường thử nghiệm và thường có các yêu cầu che giấu cho mọi thứ trừ môi trường QA và Sản xuất.


Bất cứ ai có thể giải thích các downvote?
Thất vọngWithFormsDesigner

@maple_shaft: LOL! Tôi muốn có một lời giải thích, vì vậy tôi có thể điều chỉnh câu trả lời của mình.
Thất vọngWithFormsDesigner

1
Downvote gì? Tôi không thấy downvote ...
yannis

@YannisRizos: Có một ... nhưng nó không bao giờ được giải thích.
Thất vọngWithFormsDesigner

5

Bạn dường như đã đầu tư rất nhiều nỗ lực trong việc mang lại sự thay đổi văn hóa tại nơi làm việc của bạn. Đây là một thành tựu tuyệt vời vì sự thay đổi rất khó khăn vào thời điểm tốt nhất, nhưng thay đổi văn hóa không chỉ đơn giản là thay đổi suy nghĩ của mọi người, mà là thay đổi thói quen, phá vỡ định kiến ​​và cuối cùng là mở ra những suy nghĩ khép kín có khả năng lớn hơn. Vì vậy, câu hỏi để tự hỏi mình vào thời điểm này là "Tôi đã bỏ lỡ điều gì?". Câu trả lời dễ dàng là bạn có thể không tham gia đầy đủ vào quản lý.

Nhận mua từ quản lý là dễ dàng, nhưng thậm chí khó hơn là nhận được chấp nhận. Bất kể những tranh luận về tiền, v.v., thực tế là bạn cần có khả năng ảnh hưởng đến quan điểm ưu tiên của ban quản lý. Người quản lý của bạn sẽ có ngân sách và sẽ muốn chứng minh rằng ngân sách đã được áp dụng hợp lý và phù hợp với các giá trị và ưu tiên của công ty. Một số ưu tiên đó sẽ là tài chính, nhưng những ưu tiên khác sẽ là về phục vụ các nhu cầu khác. Trong một số trường hợp, điều này có thể có nghĩa là làm tăng lòng bàn tay của những người quản lý khác để có được sự thăng tiến mà sếp của bạn luôn mong muốn. Trong hầu hết các trường hợp, có thể sẽ là tìm cách để có được nhiều doanh nghiệp hơn, hoặc cải thiện mối quan hệ với các đối tác và khách hàng. Nếu bạn không thể đưa ra trường hợp của mình theo các điều khoản này, bạn sẽ chỉ có thể đi xa hơn trước khi bạn thấy mình bế tắc.

Đề nghị của tôi là cố gắng đưa ra một trường hợp về năng suất và làm thế nào điều này ảnh hưởng đến ngân sách, như những người khác đã đề xuất, nhưng cũng nên đưa ra trường hợp theo các ưu tiên của công ty bạn và cách năng suất của bạn có thể ảnh hưởng trực tiếp đến mối quan hệ của công ty với các công ty khác.


"Thay đổi thói quen, phá vỡ định kiến ​​và cuối cùng là mở ra những suy nghĩ có khả năng đóng kín với những khả năng lớn hơn" - nhìn lại đây là chìa khóa và tôi không thể chỉ ra bất kỳ lý do duy nhất nào về lý do tại sao nó lại xảy ra
smp7d

4

Đây là một: khả năng kiểm tra.

Có một môi trường thử nghiệm cho phép bạn tự do thực hiện các thử nghiệm trên cơ sở dữ liệu mà không thể thực hiện được trong môi trường sản xuất.


4

Bạn muốn thay đổi cách tổ chức của bạn phát triển phần mềm của nó? Quên lo lắng về "lý do" cho "làm việc khác đi". Con người không thay đổi hành vi vì những lý lẽ hợp lý. Họ thay đổi vì ảnh hưởng tâm lý đến thói quen của họ.

Vì vậy, tôi đang đi đâu với điều này?

Mặc dù đôi khi bạn có thể thay đổi thành công hành vi của một tổ chức thông qua tranh luận, có những chiến thuật khác hoạt động tốt hơn. Bao gồm các:

  • Hỗ trợ cơ sở: Tìm MỘT nhà phát triển "di sản" khác, những người sẵn sàng cung cấp cho bạn một shot. Hợp tác với anh ta và thay đổi cách mọi thứ hoạt động. Đừng thông báo thay đổi. Chỉ cần thực hiện thay đổi. Nếu bất cứ ai từng hỏi bạn về điều đó, chỉ cần nói "Ồ vâng, đó là cách chúng tôi làm bây giờ."

  • Chịu trách nhiệm. Tình nguyện để xử lý việc triển khai cho những người kế thừa. Hành động như bạn thích nó. Họ có thể vui vẻ từ bỏ trách nhiệm đó. Sau đó chạy nó như thế nào bạn muốn.

  • Đổ lỗi cho đúng người cho những sai lầm của họ. Lần tiếp theo, một lỗi ứng dụng cũ được đưa vào sản xuất do cơ chế triển khai thời kỳ đồ đá của bạn, hãy chỉ ra. Làm điều đó một cách tinh tế ... Không phải trong một email. Lần tới khi bạn đang họp với người quản lý, chỉ cần tình cờ đề cập đến ví dụ về lý do triển khai có vấn đề. "Vâng, hãy nhớ làm thế nào chúng ta đã tranh giành vào thứ Sáu tuần trước vì lỗi Foo mà Bob đã kiểm tra sản xuất? Vâng, đó là rất nhiều nỗ lực lãng phí!"

  • Làm cho nó dễ dàng để làm điều đó một cách tốt hơn. Nhìn vào iphone chẳng hạn. Có một nút trên đó. (Vâng, hai). Thật dễ dàng để bật. Làm cho việc triển khai đến nhiều môi trường trở nên điên rồ dễ dàng. Làm cho nó dễ dàng tất cả các nhà quản lý có thể làm điều đó!


Humans don't change behavior because of rational arguments. They change because of psychological influences on their habits. Thật là chán nản thật đấy. Cho dù nói đến phần mềm hay "thị trường tự do", niềm tin rằng mọi người đưa ra quyết định hợp lý vì lợi ích tốt nhất của họ là một lời ngụy biện.
maple_shaft

4

Đó là vấn đề nhiều hơn khi bạn bắt đầu xử lý các hệ thống kết nối hoặc kế thừa, hệ thống mà doanh nghiệp phụ thuộc vào hoạt động và chính xác. Điều này quan trọng bởi vì cần phải có sự tách biệt giữa các giai đoạn, đó là lý do tại sao bạn không DEV trên SẢN PHẨM vì nó có khả năng gây ra thiệt hại trị giá hàng triệu đô la trong thời gian bị mất .

Chúng tôi luôn luôn thực hiện DEV -> QA -> SẢN PHẨM (đôi khi các bước đó được chia thành các phần nhỏ hơn) với phần cứng giống hệt nhau phía sau chúng. Dữ liệu sản xuất hiện tại luôn được đẩy từ SẢN XUẤT sang QA sang DEV.

DEV: được dự định là hộp cát phát triển, nơi mọi thứ được thử, lặp đi lặp lại và đánh bại trên bất kỳ dữ liệu nào trong môi trường này sẽ không bao giờ được tin cậy và thường xuyên bị các nhà phát triển tìm cách giải quyết vấn đề.

QA: Một khi các nhà phát triển của bạn hài lòng với thử nghiệm đơn vị, đã đến lúc nhóm thử nghiệm có được điều đó. Họ chạy các trường hợp thử nghiệm, kiểm tra hiệu suất và tìm lỗi. Những lỗi / enchancements được đưa trở lại DEV và chu kỳ tiếp tục cho đến khi mọi người hài lòng.

SẢN XUẤT: Khi bạn đã đến giai đoạn này, bạn nên chắc chắn mã hoạt động cùng với dữ liệu hiện tại và người dùng nhóm / doanh nghiệp QA của bạn hài lòng với việc triển khai. Nếu bạn đã làm mọi thứ chính xác, bạn chỉ cần có thể cập nhật mã và được thực hiện với nó.

Theo cùng một cách bạn sẽ không bao giờ phát hành một sản phẩm chưa được kiểm tra cho khách hàng, bạn không bao giờ nên phát hành mã chưa được kiểm tra cho môi trường sản xuất.

Nếu công ty không sẵn sàng đầu tư thời gian để làm điều đó đúng cách, họ sẽ trả lại chi phí trong bảo trì khẩn cấp và lỗi gấp 10 lần.

Một ví dụ nhỏ: Chúng tôi đã có một công ty quyết định thay đổi báo cáo trong sản xuất. Không ai biết rằng nó đã thay đổi cho đến khi chúng tôi đến để giải quyết một loạt các vấn đề một hoặc hai năm.

Khi chúng tôi chỉ ra sự bất thường trong báo cáo, khuôn mặt của CFO trở nên trắng bệch, hóa ra họ đã mất ~ 250.000 đô la một quý vì ai đó thực hiện thay đổi nhanh chóng.

Xảy ra thường xuyên hơn sau đó bạn nghĩ, nếu bạn không đủ khả năng để làm điều đó đúng thì đừng làm.


Ví dụ tốt đẹp. Tất nhiên, trách nhiệm giải trình là một lý do quan trọng để phân tách DEV và SẢN XUẤT. Bằng cách đó, bạn có thể kiểm soát cực kỳ nghiêm ngặt đối với SẢN PHẨM, đồng thời mang lại cho DEV sự tự do cần thiết.
sleske

3

Quản lý có một phần lớn đằng sau sự thành công của các Công ty Phần mềm và Sản phẩm Phần mềm cần có để tạo ra các môi trường này. Hãy lấy một ví dụ về dự án của bạn. Nếu phần mềm của bạn được phát triển trên quy mô lớn thì nếu bạn không quản lý các yêu cầu dự án của mình, kiểm soát quy trình, Test Builds, thì đây là cơ hội thất bại. để Quản lý dự án tồn tại.

Tôi phần nào đồng ý với @ Stargazer712 rằng tuyên bố của bạn chỉ ra vấn đề Tiền bạc, nhưng Hãy kiểm tra tuyên bố sau mà tôi đã nhận được từ cuốn sách của Marc Hamilton về Phát triển phần mềm: Xây dựng hệ thống đáng tin cậy (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Sau khi xem xét tất cả các yếu tố này; Ý kiến ​​của tôi về câu hỏi của bạn là Môi trường đơn lẻ không giúp bạn tiết kiệm, nó sẽ thực hiện một quá trình lâu dài để hoàn thành dự án / phần mềm. Môi trường phân tán sẽ tiết kiệm thời gian và doanh thu như tôi đã học và thấy trong kinh nghiệm của mình rằng những gì đã xảy ra với các công ty phần mềm khởi nghiệp mà tôi đã bắt đầu vận chuyển.

Có rất nhiều bài viết chứng minh rằng vấn đề thành công là gì, hãy xem bài này Tổ chức để phát triển phần mềm thành công

Mỗi cá nhân trong một tổ chức đều có những kỹ năng nhất định và những kỹ năng này thường được đo lường dựa trên các số liệu hiệu suất chính thức hoặc không chính thức dẫn đến phần thưởng (bồi thường) là những khuyến khích cho hiệu suất trong tương lai. Những người trong một tổ chức thiết lập văn hóa của mình, đó là những kiểu hành vi và giá trị thường được công nhận là được thông qua.

Một nhóm lớn các nhà phát triển phần mềm sẽ đấu tranh và cuối cùng không đạt được mục tiêu nếu họ phải dành toàn bộ thời gian để chống lại một cấu trúc tổ chức không phù hợp.

Nhiều phần mềm khởi động bắt đầu cuộc sống với không nhiều hơn một vài nhà phát triển làm việc trong nhà để xe. Không có nhiều cấu trúc tổ chức được yêu cầu tại thời điểm này trong lịch sử của công ty, nhưng cấu trúc tổ chức vẫn tồn tại. Chẳng hạn, vào năm 1977, khi Bill Gates và Paul Allen thành lập quan hệ đối tác và chính thức đặt tên là Microsoft, công ty có cơ cấu tổ chức tối thiểu. Ít hơn một tá nhân viên làm việc tại văn phòng đầu tiên của Microsoft ở Albuquerque, New Mexico và mọi người đều biết ai chịu trách nhiệm. Không có biểu đồ tổ chức phức tạp nào là cần thiết để tìm ra cấu trúc báo cáo của mọi người. Đồng thời, tất cả nhân viên đều biết vai trò của họ trong công ty và những gì họ đang cố gắng thực hiện. Điều này là do bất kỳ cấu trúc tổ chức nào cần thiết đều có thể được truyền đạt không chính thức giữa mỗi nhân viên.


1

Quên thời gian, tiền bạc, khả năng kiểm tra, chất lượng ... làm thế nào về danh tiếng .

lý do tốt, đơn giản, không thể bác bỏ để phân tách các môi trường sẽ khiến các nhà quản lý thiếu kinh nghiệm phát triển để hỗ trợ ý tưởng này.

Uber gần đây đã chuyển mã tới github có chứa mật khẩu cho môi trường sống của họ , cho phép 'tin tặc' tải xuống tất cả các chi tiết khách hàng của họ. Uber nói rằng đó là một sự vi phạm, mọi người khác nói rằng "đừng đưa chìa khóa vào ổ khóa của bạn ở chế độ công khai. Nếu nhà phát triển của họ làm việc hoàn toàn trên môi trường dev, họ có thể đã phát hành khóa cho môi trường dev của họ trên github, nhưng đó hoàn toàn là Điều đó vô hại. Những sản phẩm được phát hành cho thấy ý tưởng thực hiện dev trên môi trường sản xuất kém đến mức nào.

Chỉ cần nhắc nhở người quản lý của bạn rằng những sai lầm xảy ra, vì vậy cách để tránh anh ta bị lôi ra trước vị CEO sắp bị nướng trước mặt các nhà báo và bị công chúng công nghệ cười nhạo là thực hiện những bước đơn giản, rõ ràng để ngăn chặn những sai lầm đó trở thành thảm họa những cái.


1

Âm thanh như bạn phải đến nhiều môi trường khác nhau và mọi người phải mất nhiều thời gian để thiết lập một "môi trường".

Bạn nên có số lượng "môi trường" khác nhau ít nhất mà bạn có thể thoát khỏi, nhưng có thể sao chép nhiều bản sao vì nhiều lý do mà bạn và công ty mong muốn (sử dụng "môi trường để hiểu cấu hình hệ thống)!

Tối ưu sự khác biệt duy nhất nên là:

  1. Kích thước (tối thiểu, được khuyến nghị, được hỗ trợ / thử nghiệm lớn nhất);
  2. Dàn dựng và sản xuất không có công cụ phát triển
  3. Sản xuất được bảo vệ chống lại việc ghi đè dữ liệu ngẫu nhiên
  4. Bạn có thể rất dễ dàng tải dữ liệu máy khách demo, thử nghiệm hoặc [anoymized] vào máy chủ phát triển hoặc dàn dựng

THEN câu hỏi bao nhiêu và loại thử nghiệm nào nên được thực hiện là một đánh giá kinh doanh rủi ro / chi phí và quyết định ở cấp độ công ty, bởi vì toàn bộ doanh nghiệp sẽ phải chịu đựng nếu lỗi nghiêm trọng xảy ra với một loạt khách hàng .

Chỉnh sửa sau: Điều này nhắc tôi hợp lý hóa các quy ước đặt tên với các sản phẩm web của mình (cảm ơn vì câu hỏi). Tôi đã quyết định bốn "môi trường", với thử nghiệm phân tách giữa qa (tầng đơn tối thiểu chỉ cho chức năng kiểm tra) và dàn dựng (cùng kiến ​​trúc như sản xuất, để kiểm tra tải / hiệu suất / khối lượng).

Sự khác biệt thực sự duy nhất trong việc cung cấp là sản xuất / dàn dựng cài đặt DB cho một hệ thống riêng biệt mà tôi kiểm soát bởi các nhóm máy chủ khác nhau. Qa / dev có cả vai trò máy chủ web và db. Cân bằng tải được thực hiện bởi cloudflare.

Tôi cũng có một biến ENV_NO, được truyền vào các hệ thống để tôi có thể chọn có nhiều ví dụ "qa" hoặc "dàn dựng" như tôi chọn.

Vì vậy, để thiết lập môi trường qa thứ hai bao gồm bản sao lưu mới nhất của tôi từ trực tiếp, các lệnh sẽ là:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Cuối cùng, tôi có thêm một máy chủ (tùy chọn) được gọi là "readonly" là mạng an toàn cuối cùng trước khi chạm đất. Nó được cung cấp giống như một hệ thống qa nhưng với bản sao lưu và cập nhật đêm qua bị vô hiệu hóa (phần mềm cũng được cập nhật vào tối qua).

Nó sử dụng phương pháp "Tất cả trứng trong một giỏ khác nhau": Nó được cung cấp với một công ty đăng ký DNS / địa điểm khác nhau, máy chủ DNS, nhà cung cấp dịch vụ lưu trữ hệ thống. Đây là mạng lưới an toàn cuối cùng / cuối cùng, vì vậy nếu mọi thứ bùng cháy, ít nhất bạn có thể lấy dữ liệu đến tối qua. Các tập lệnh cung cấp tách biệt sự khác biệt giữa các nhà cung cấp khác nhau, vì vậy 99% là như nhau, chỉ là cờ chỉ đọc. Bộ cân bằng tải Cloudflare sẽ chuyển hướng lưu lượng truy cập đến trang web chỉ đọc nếu tất cả các máy chủ trực tiếp bị lỗi.


0

Khi nói đến việc thực hiện thay đổi, bạn sẽ may mắn có một người chỉ lắng nghe ý kiến ​​chuyên môn của bạn và thực hiện các thay đổi được đề xuất.

Theo kinh nghiệm của tôi, mỗi lần tôi phải thực hiện một thay đổi lớn, tôi phải chứng minh điều đó về khoản tiết kiệm mà doanh nghiệp sẽ thực hiện. Ví dụ, giới thiệu ReSharper vào đường ống phát triển khá dễ dàng, vì tôi có thể nói điều gì đó trên đường tắt:

ReSharper có giá khoảng £ 50 mỗi nhà phát triển. Chi phí phát triển trung bình mỗi năm là £ 40k. ReSharper nên tăng năng suất của các nhà phát triển ít nhất 20% khi sử dụng hết tiềm năng của nó. Nói rằng nhà phát triển dành 75% thời gian của họ thực sự viết mã trong IDE. 75% của 40k là £ 30k. £ 30k bây giờ là chi phí năng suất của nhà phát triển. Một phần trăm bổ sung của năng suất (1%) mỗi năm có giá 300 bảng. Để có thêm 20% năng suất, doanh nghiệp sẽ phải chi £ 6k.

Nếu bạn đặt điều này vào viễn cảnh cho doanh nghiệp, bạn có thể nói rằng bạn có thể thuê người khác và nhận thêm 20% năng suất với giá 6 nghìn bảng hoặc bạn có thể nhận được kết quả tương tự bằng cách chi 50 bảng cho giấy phép ReSharper. Một khi các số liệu ở phía trước của doanh nghiệp, quyết định sẽ dễ dàng đưa ra.

Bây giờ liên quan đến câu hỏi của bạn có nhiều môi trường, tất cả những gì bạn phải làm là tìm cách tính toán chi phí cho doanh nghiệp mỗi năm để có những môi trường này.

Bạn có thể yêu cầu các nhà phát triển đồng nghiệp của mình theo dõi số giờ đã dành mỗi tuần để định cấu hình các ứng dụng để phát triển, triển khai, v.v. Ví dụ: mười giờ thời gian của nhà phát triển cao cấp có thể tiêu tốn 500 bảng. Đó là 10 giờ có thể dành cho phát triển, hoặc một cái gì đó quan trọng hơn nhiều. Bạn thu thập các số liệu trong một khoảng thời gian và cung cấp cho doanh nghiệp một chi phí hàng năm.

Cá nhân tôi ghét loại chính trị này, nhưng nó phổ biến và chúng ta phải sống với nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.