Khi đồng nghiệp của tôi nghĩ rằng không cần thử nghiệm trên PC của anh ta, anh ta thực hiện thay đổi, cam kết và sau đó đẩy. Sau đó, anh ta kiểm tra trên máy chủ sản xuất và nhận ra rằng mình đã phạm sai lầm. Nó xảy ra một lần trong một tuần. Bây giờ tôi thấy rằng anh ta đã thực hiện 3 lần cam kết và thúc đẩy triển khai đến máy chủ sản xuất trong vòng 5 phút.

Tôi đã nói với anh ta vài lần rằng đây không phải là cách làm việc tốt. Tôi không muốn thô lỗ với anh ta một lần nữa và anh ta ở cùng địa vị với tôi trong công ty và anh ta đã làm việc nhiều hơn tôi ở đây.

Tôi muốn hành vi này bị trừng phạt theo một cách nào đó hoặc làm cho nó khó chịu nhất có thể.

Trước khi tôi bắt đầu, công ty đã triển khai bằng các phương pháp cổ, chẳng hạn như FTP và không có kiểm soát phiên bản.

Tôi đã buộc họ / chúng tôi sử dụng Git, Bitbucket, Dploy.io và HipChat. Việc triển khai không tự động, ai đó phải đăng nhập vào dply.io và nhấn nút triển khai.

Bây giờ, làm thế nào tôi có thể buộc họ không kiểm tra trên máy chủ sản xuất? Một cái gì đó giống như bot HipChat có thể cảm nhận rằng có nhiều lần chỉnh sửa trên cùng một dòng và gửi thông báo cho lập trình viên.

Bạn cần một quy trình Đảm bảo Chất lượng (QA) thích hợp.

Trong nhóm phát triển phần mềm chuyên nghiệp, bạn không được chuyển từ quyền phát triển sang sản xuất. Bạn có ít nhất ba môi trường riêng biệt: phát triển, dàn dựng và sản xuất.

Khi bạn nghĩ rằng bạn đã có một cái gì đó hoạt động trong môi trường phát triển của mình, bạn sẽ chuyển sang giai đoạn đầu tiên, trong đó mỗi cam kết được nhóm QA kiểm tra và chỉ khi thử nghiệm đó thành công, nó mới được đẩy vào sản xuất. Lý tưởng nhất là phát triển, thử nghiệm và đẩy mạnh sản xuất được thực hiện bởi những người riêng biệt. Điều này có thể được đảm bảo bằng cách định cấu hình hệ thống tự động hóa xây dựng của bạn theo cách mà các nhà phát triển chỉ có thể triển khai từ phát triển đến dàn dựng và nhóm QA chỉ có thể triển khai từ dàn dựng đến sản xuất.

Khi bạn không thể thuyết phục ban quản lý thuê ai đó làm QA, thì có lẽ một trong hai bạn có thể đóng vai trò đó cho người kia. Tôi chưa bao giờ làm việc với diploy.io, nhưng một số hệ thống tự động hóa xây dựng có thể được cấu hình theo cách mà người dùng có thể triển khai cả từ phát triển đến dàn dựng và từ dàn dựng đến sản xuất, nhưng không làm cả hai cho cùng một bản dựng, vì vậy người thứ hai luôn luôn bắt buộc (nhưng hãy chắc chắn rằng bạn có một số người dự phòng nhiều lần khi một trong hai bạn vắng mặt).

Một lựa chọn khác là yêu cầu nhân viên hỗ trợ của bạn thực hiện QA. Điều này có vẻ như là công việc bổ sung cho họ, nhưng nó cũng đảm bảo rằng họ biết về bất kỳ thay đổi nào đối với ứng dụng có thể đảm bảo an toàn cho họ một số công việc trong thời gian dài.

Bạn có thể sẽ muốn có được một máy chủ dev và tốt nhất là môi trường dàn dựng. Không ai nên đẩy từ địa phương sang sản xuất ngoại trừ trang web cá nhân của riêng họ. Quá trình triển khai của bạn chỉ nên hỗ trợ dev-> staging-> prod. Bạn có thể muốn ai đó chịu trách nhiệm đăng xuất các bản phát hành mới - tùy thuộc vào tổ chức, đây có thể là người dẫn đầu dự án, QA chuyên dụng hoặc nhiệm vụ xoay vòng mỗi tuần (với lời nhắc nhở hữu hình, ví dụ như chỉ có người có đồ chơi lông bông trong tuần đẩy). Tuy nhiên, trước tiên hãy thảo luận với nhóm của bạn để mua hàng (xem bên dưới).

Tôi muốn hành vi này bị trừng phạt theo một cách nào đó hoặc làm cho nó khó chịu nhất có thể.

Bạn có thể có bộ kiểm tra của mình (bạn đã có một trong số đó, phải không?) Bao gồm một kiểm tra xác định xem bạn có ở trên máy chủ sản xuất không và nếu có, sẽ gửi cho mọi người trong văn phòng một email nói Looks like $username is testing on prod, watch out. Có lẽ công khai xấu hổ đồng nghiệp của bạn sẽ là khó chịu. Hoặc bạn có thể tạo các hạn chế kỹ thuật như IP - cấm nhóm của bạn nhìn vào prod (bạn có thể nâng nhưng bạn phải biện minh).

Tuy nhiên, tôi không khuyên bạn nên xem xét vấn đề, chứ không phải người đang thử nghiệm sản phẩm và bạn có thể khiến bản thân không được lòng những người trong nhóm không quan tâm.

Chắc chắn những gì bạn thực sự muốn không phải là để hành vi này bị trừng phạt mà là để nó dừng lại ?

Tôi đã buộc họ / chúng tôi sử dụng [...]

Thật tuyệt khi bạn đang ủng hộ cải tiến quy trình làm việc, nhưng có vẻ như bạn không nghĩ nhiều về đồng nghiệp của mình và / hoặc bạn không có sự hỗ trợ đầy đủ của họ. Điều này có thể dẫn đến việc các đồng nghiệp tương tác nửa vời với quy trình làm việc, làm tối thiểu cần thiết để đưa mã vào sản xuất và không thực sự tuân theo tinh thần của quy trình làm việc, điều này có nghĩa là sẽ mất nhiều thời gian hơn để làm sạch. Và khi bạn dành nhiều thời gian hơn để làm sáng tỏ kết quả của sự tương tác không đầy đủ với quy trình làm việc (vì không ai khác quan tâm chứ?) Mọi người khác sẽ tự đặt câu hỏi cho quy trình làm việc.

Vì vậy, bắt đầu với một cuộc trò chuyện.

Tìm hiểu lý do tại sao điều đó xảy ra (máy của đồng nghiệp của bạn không tốt để thử nghiệm phải không? Đồng nghiệp của bạn không chắc chắn với các nhánh tính năng hoặc bị mắc kẹt trong suy nghĩ svn khi cam kết và đẩy giống nhau?), Giải thích tại sao đó là vấn đề đối với bạn mà mã chưa được kiểm tra trên dev / staging / prod, và xem liệu bạn có thể làm gì đó để thay đổi lý do tại sao không (đồng nghiệp của bạn sẽ có nhiều khả năng làm những gì bạn muốn nếu bạn vừa làm cho nó tốt hơn để kiểm tra cục bộ so với khi bạn vừa mắng họ).

Nếu bạn không thể giải quyết nó và nó thực sự dẫn đến sự khác biệt về quan điểm, hãy lên lịch thảo luận toàn đội trong cuộc họp hồi cứu tiếp theo của bạn, xem đồng nghiệp của bạn làm gì và nghĩ gì. Làm cho trường hợp của bạn, nhưng lắng nghe sự đồng thuận. Có thể nhóm của bạn nói rằng không nên kiểm tra các bản sửa lỗi văn bản cục bộ và bạn chỉ có một quy tắc là không có tính năng lớn nào được đưa vào dev chưa được kiểm tra. Viết ra trong cuộc họp và đọc những gì bạn quyết định chung về những gì được phép trên mỗi môi trường. Đặt một ngày trong một vài tháng để xem xét nó, có thể ở một hồi cứu.

Trong công việc, chúng tôi tránh điều này bằng cách sử dụng Gerrit . Gerrit là một hệ thống đánh giá mã hoạt động như một cổng vào chi nhánh Git chính / sản xuất của bạn, thường được gọi là "chính". Bạn có mã đánh giá, phải không? Có vẻ như cá nhân bạn làm chúng đặc biệt. Với Gerrit, bạn chuyển sang một nhánh phân nhánh, sau khi bạn và đồng nghiệp của bạn đã thực hiện quy trình xem xét mã một cách thỏa đáng, Gerrit sau đó hợp nhất với nhánh chính của bạn. Bạn thậm chí có thể nối Gerrit với máy chủ CI để thực hiện kiểm tra đơn vị trước khi bất kỳ ai nhận được email để xem xét thay đổi. Nếu bạn không có máy chủ, bạn có thể thiết lập công cụ CI, Codeship có một gói miễn phí tốt để sử dụng làm bằng chứng về khái niệm.

Cuối cùng, tất nhiên, là để tự động hóa việc triển khai sản xuất chỉ từ các sản phẩm xây dựng bị xử phạt còn tồn tại trong quá trình đánh giá mã và thử nghiệm đơn vị. Có một số công nghệ tuyệt vời được đưa ra cho điều này, mà tôi sẽ không đề cập đến vì sợ nó sẽ là mồi lửa.

Đi đến ông chủ của bạn với một giải pháp. Điều này áp dụng ngay cả với bạn và là một cách để cải thiện chất lượng mã của mọi người, không chỉ trừng phạt đồng nghiệp của bạn.

Tôi thấy đây là một vấn đề lớn của con người - quá trình ở đó và các công cụ ở đó, nhưng quá trình này không được tuân thủ.

Tôi đồng ý với những gì người khác đã nói ở đây, về khả năng nhà phát triển đang nghi vấn chỉ bị mắc kẹt trong suy nghĩ của SVN và có thể nghĩ rằng anh ta đang theo dõi quá trình.

Tôi thấy rằng cách tốt nhất để giải quyết loại vấn đề này, đặc biệt là khi có thể không có cấp trên rõ ràng, không xoay quanh việc trừng phạt hoặc xóa quyền truy cập - điều này chỉ dẫn đến sự phẫn nộ và vì có vẻ như bạn là người đề xuất lớn quá trình (luôn luôn có một, và tôi đã từng là 'anh chàng đó' trước đây), bạn là người có khả năng chịu nhiệt cao nhất. Nó xoay quanh việc đưa mọi người đến thỏa thuận về quy trình đầu tiên.

Đây là nơi các cuộc họp có cấu trúc, như "bài học kinh nghiệm" - các cuộc họp sau khi xảy ra sự cố lớn trong sản xuất, có thể rất hữu ích. Hãy thử làm cho tất cả mọi người đồng ý, bao gồm cả nhà phát triển được đề cập, đánh giá mã, kiểm tra đơn vị, kiểm tra toàn diện, v.v ... tất cả đều cần diễn ra, mọi lúc (và bạn cũng có thể bắt đầu đưa ra ý tưởng về môi trường dàn dựng ở đây). Nó không phải là khó, và nó rất hợp lý. Sau đó yêu cầu nhóm đưa ra một số quy tắc vững chắc cùng nhau, về cách nó nên được thực hiện. Càng nhiều nhà phát triển gây ra vấn đề đóng góp, họ sẽ càng cảm thấy muốn tuân thủ các quy tắc và bắt đầu xem tại sao hành vi của họ lại là một vấn đề.

Điểm cuối cùng, là không bao giờ rơi vào "tốt, nó tốt hơn trước đây!" bẩy. Luôn có chỗ để cải tiến. Theo kinh nghiệm của tôi, thông thường, những người trong ngành CNTT, bắt đầu giải quyết những gì họ đã có, sau một số cải tiến. Việc giải quyết sau đó tiếp tục, cho đến khi bạn bất ngờ tại một điểm khủng hoảng một lần nữa.

Điều này không phải là hiếm , đặc biệt là trong các đội nhỏ. Đừng làm to chuyện về nó, nhưng hãy đưa ra một quy tắc không chính thức:

Phá vỡ xây dựng, mang lại bánh rán.

1) Bạn sẽ nhận được bánh rán hai lần một tuần hoặc 2) họ sẽ tuân thủ tiêu chuẩn.

Mang nó lên trong một cuộc họp. Không phải buộc tội, không đề cập đến bất kỳ ai theo tên, nhưng một cái gì đó tương tự, "Kể từ khi chúng tôi giới thiệu các tiêu chuẩn triển khai và kiểm soát phiên bản, mọi thứ trở nên dễ dàng hơn nhiều và máy chủ đã hết thời gian hơn trước đây. Thật tuyệt! Tuy nhiên, vẫn rất khó để thực hiện một phím tắt và gửi mà không cần kiểm tra đúng cách. Tuy nhiên, đó là một canh bạc và máy chủ của chúng tôi đang hoạt động. Tôi đề nghị rằng từ bây giờ nếu bất kỳ ai trong chúng tôi gửi mã phá vỡ máy chủ, người chịu trách nhiệm sẽ đưa vào bánh rán cho đội vào ngày hôm sau. "

Thay thế một cái gì đó khác cho bánh rán nếu muốn, và đừng làm nó đắt tiền - bữa trưa cho toàn đội sẽ quá nhiều, nhưng một hộp bánh rán hoặc khay trái cây / rau quả 5 đô la, hoặc khoai tây chiên và nhúng, v.v. có lẽ sẽ gây phiền nhiễu đủ để khiến họ thực sự cân nhắc rủi ro với sự thuận tiện của việc bỏ qua kiểm tra mà không biến nó thành gánh nặng sẽ đẩy họ ra khỏi nhóm hoặc công ty.

Bây giờ, làm thế nào tôi có thể ép buộc họ ...

Thay vì ép buộc đồng nghiệp của bạn, hãy thử làm cho họ nhìn mọi thứ từ quan điểm của bạn. Điều này sẽ làm cho mọi thứ dễ dàng hơn nhiều cho mọi người. Dẫn tôi vào ...

Tôi muốn hành vi này bị trừng phạt theo một cách nào đó hoặc làm cho nó khó chịu nhất có thể.

Tại sao nó là một nỗi đau cho bạn với các vấn đề trên máy chủ trực tiếp, nhưng không phải cho anh chàng này? Bạn có biết cái gì mà anh ấy không? Bạn có thể làm gì để khiến anh ấy nhìn mọi thứ theo cách bạn làm?

Nếu bạn thành công với điều này, bạn sẽ đưa ra những điều tốt nhất ở anh ấy và anh ấy sẽ tìm ra giải pháp cho vấn đề mà bạn chưa bao giờ nghĩ tới.

Nói chung, hãy cố gắng làm việc cùng với mọi người để giải quyết vấn đề thay vì buộc họ vào các quy trình không hiểu.

Điều tồi tệ nhất có thể xảy ra là gì? Bạn có bản sao lưu đủ tốt để sửa lỗi bản ghi ngẫu nhiên trong cơ sở dữ liệu của bạn bằng cách khôi phục phiên bản cũ không?

Giả sử bạn có một lỗi trong đó bạn sử dụng id hồ sơ và do nhầm lẫn, số tiền tính bằng xu được lưu trữ trong một biến được sử dụng cho id hồ sơ. Vì vậy, nếu tôi trả $ 12,34 thì hồ sơ với id 1234 sẽ được sửa đổi. Bạn có thể phục hồi từ đó không, nếu phần mềm chạy trong vài giờ cho đến khi phát hiện ra lỗi? (Nếu cả bản ghi chính xác và bản ghi 1234 được cập nhật, bạn sẽ chỉ phát hiện ra điều này khi bản ghi 1234 được sử dụng, do đó, bản ghi này có thể không bị phát hiện trong một thời gian dài).

Bây giờ hãy hỏi nhà phát triển có động lực cao của bạn xem anh ấy nghĩ gì về điều này. Rõ ràng anh ta không thể tuyên bố rằng anh ta không bao giờ phạm sai lầm, bởi vì anh ta đã làm như vậy trong quá khứ.

Bạn hiểu rõ các quy trình và giải pháp kỹ thuật có thể. Vấn đề là làm thế nào để quản lý đồng nghiệp.

Đây thực chất là một bài tập quản lý thay đổi.

Đầu tiên, tôi sẽ có một lời thầm lặng với người sáng lập để đảm bảo anh ấy / cô ấy ở trên tàu với quan điểm của bạn. Nếu có sự cố ngừng sản xuất, tôi hy vọng rằng người sáng lập sẽ rất quan tâm đến điều đó và mong muốn thay đổi.

Thứ hai, bạn làm việc trong một nhóm nhỏ và có thể đáng để cố gắng khiến cả nhóm tham gia vào quá trình cải tiến.

Thiết lập quá trình hồi cứu quy trình thường xuyên (ví dụ hàng tuần). Có cả đội:

• Xác định vấn đề
• Ý tưởng tình nguyện để cải thiện thực hành công việc
• Tham gia thực hiện những thực hành đó

Nó nên tuân theo một cách tự nhiên rằng toàn bộ nhóm sau đó cũng giúp đảm bảo tuân thủ các thực tiễn được cải thiện.

Tôi nghĩ bạn đã xác định được một vài vấn đề:

1. Có vẻ như bất kỳ mã nào được kiểm tra đều có thể bị đẩy vào sản xuất một cách tầm thường bởi bất kỳ ai có quyền kiểm tra mã.

Thành thật mà nói tôi nghĩ rằng thiết lập chỉ là điên rồ. Tối thiểu, những người có thể tự kích hoạt việc đẩy sản xuất nên được giới hạn ở nhóm người có thể tin tưởng hoàn toàn để xem xét kỹ lưỡng và kiểm tra tất cả các thay đổi bên ngoài (bất kể ai là tác giả của các thay đổi) trước khi kích hoạt đẩy. Cho phép bất cứ ai có quyền kiểm tra mã nguồn cũng tùy tiện kích hoạt một cú hích để sản xuất chỉ là vấn đề rắc rối. Không chỉ từ các nhà phát triển bất cẩn và / hoặc bất tài, mà còn từ những người bất mãn hoặc các bên thứ ba độc hại tình cờ thỏa hiệp một trong các tài khoản của bạn.

Và nếu bạn sẽ sử dụng quy trình nhấn nút để triển khai mọi thay đổi được kiểm tra, thì bạn cần phải có một bộ kiểm tra tự động toàn diện, và nhấn nút cần phải chạy chúng (và hủy bỏ việc triển khai nếu bất kỳ bài kiểm tra nào thất bại!). Quá trình của bạn không nên cho phép mã thậm chí chưa được kiểm tra một cách hời hợt để đạt đến điểm mà nó đang được triển khai cho hệ thống sản xuất ngay từ đầu.

Đồng nghiệp của bạn đã phạm một sai lầm lớn về mặt kiểm tra mã mà không kiểm tra trước. Tổ chức của bạn đã có một sai lầm lớn hơn nhiều bằng cách áp dụng quy trình triển khai cho phép mã chưa được kiểm tra tiếp cận sản xuất trong mọi trường hợp.

Vì vậy, thứ tự đầu tiên của doanh nghiệp là sửa chữa quá trình triển khai. Hoặc giới hạn người có thể kích hoạt thúc đẩy sản xuất hoặc kết hợp một lượng thử nghiệm hợp lý vào quy trình triển khai tự động của bạn hoặc cả hai.

2. Có vẻ như bạn có thể không đặt ra bất kỳ tiêu chuẩn / nguyên tắc phát triển nào được xác định rõ ràng.

Cụ thể, có vẻ như bạn đang thiếu một " định nghĩa hoàn thành " rõ ràng và / hoặc sử dụng một định nghĩa không bao gồm "mã đã được kiểm tra" như là một yếu tố quyết định trong việc kiểm tra mã trong / triển khai mã để sản xuất. Nếu bạn đã có điều này, thay vì chỉ chỉ ra rằng "mã tốt không được tạo ra theo cách này", bạn có thể nói "mã này không đáp ứng các tiêu chuẩn tối thiểu mà tất cả chúng ta đã đồng ý, và nó cần phải tốt hơn trong Tương lai".

Bạn nên cố gắng thiết lập một nền văn hóa truyền đạt rõ ràng những gì các nhà phát triển mong đợi và các tiêu chuẩn cũng như mức độ chất lượng mà họ dự định duy trì. Thiết lập một định nghĩa hoàn thành bao gồm ít nhất là kiểm tra thủ công (hoặc tốt nhất là các kiểm thử tự động có thể được chạy như một phần của quy trình xây dựng / triển khai) sẽ giúp ích cho việc đó. Như có thể có hậu quả cho việc phá vỡ các tòa nhà. Hoặc hậu quả nghiêm trọng hơn cho việc phá vỡ hệ thống sản xuất. Lưu ý rằng hai điều đó phải thực sự độc lập và hoàn toàn không thể phá vỡ cả bản dựng và hệ thống sản xuất (vì các bản dựng bị hỏng không bao giờ có thể triển khai được).

Bạn nên tích hợp quy trình Đánh giá ngang hàng + Tích hợp liên tục trong công ty. Bitbucket làm cho nó dễ dàng.

Và +1 cho máy chủ dev được đề xuất bởi người dùng khác.

Đừng thô lỗ với anh ta, điều đó sẽ chỉ làm tổn thương mối quan hệ công việc của bạn.