RAD 환경에서 릴리스 품질을 향상시키는 간단한 방법

여기에 약간의 배경이 있습니다. 우리는 대기업이 아닌 소프트웨어 회사의 내부 소프트웨어 개발을 담당하는 RAD 개발자로 구성된 소규모 팀 (5 명)입니다. "내부 소프트웨어"는 MSSQL 서버를 백엔드로 사용하는 데스크톱 .NET 응용 프로그램과 백그라운드에서 실행되는 Python 스크립트의 백엔드 인 MS Word 문서 및 템플릿 (기술 동물원)에 따라 다릅니다.

전체 팀은 사용자로부터 요구 사항을 가져 와서 코딩하고 테스트하며 프로덕션 환경에 배포 할 수있는 올 로더로 구성됩니다. 프로덕션 환경의 소프트웨어는 다른 팀에서 관리하지만 문제가 발생하면 쉽게 개입 할 수 있습니다.

지금까지 모든 것이 잘 들리지만 문제가 있습니다. RAD 팀이 되려면 자주 출시해야하며, 하나 또는 두 개의 응용 프로그램의 새 버전을 출시하지 않고는 하루가 없습니다 (또는 스크립트, 업데이트 된 단어 문서 일 수 있음) , C ++ 콘솔 앱 등)을 프로덕션에 삽입하십시오. 우리는 개발 테스트를 수행하고 최종 사용자가 UAT 환경에서 소프트웨어를 실행하도록하여 최종 사용자를 참여시킵니다.

...하지만 버그는 어쨌든 생산에 들어오고 있습니다. 사용자는 이러한 버그와 가끔 불안정성이 실제로 원하는 것을 빨리 얻기 위해 지불하는 가격이라는 것을 이해하지만 동시에 우리는 생각을 얻었습니다. 아마도 개발을 개선하거나 릴리스 관행의 안정성을 향상시킬 수 있습니다. 새로운 기능을 추가 할 때 소개하는 버그 수를 줄입니다.

좋은 점은-처음에는 프로세스가 많지 않기 때문에 개선하기가 쉽고, 나쁜 점은-구현할 시간과 리소스가 거의없는 소규모 RAD 팀이라는 것입니다. 우리는 다음과 같은 이니셔티브에 대해 생각하고 있으며 피드백, 팁, 힌트 및 제안을 환영합니다.

1. 현재 일부 응용 프로그램은 사용자 테스트를 거치지 않고 개발자 테스트 직후 프로덕션에 출시됩니다. 이러한 관행은 중단되어야하며 최종 사용자는 약간의 변경도 테스트해야합니다. 각 응용 프로그램에는 최종 사용자가 선택한 전용 베타 테스터가 있습니다. 베타 테스터가 새 릴리스를 확인한 후에 만 ​​테스트에서 프로덕션 환경으로 승격됩니다.

2. 우리는 코드 검토를 수행하지 않지만 우리 중 하나가 변경 세트를 체크인하기 전에 코드 검토를 시작합니다. 또한 "롤아웃 검토"에 대해 생각하고있었습니다. 기본적으로 개발자 중 한 명이 소프트웨어 롤아웃 (이진 복사, 구성 업데이트, 데이터베이스에 새 테이블 추가 등)을하는 다른 사람과 나란히 앉아 있어야합니다. 5 ~ 10 분이 걸리므로 "롤아웃 검토"시간이 많이 걸리지 않습니다.

3. 새로운 릴리스가 프로덕션에서 풀 아웃되고 이전 버전으로 교체하기에 충분히 버그가있는 것으로 판명 될 때 롤백 시간을 줄이는 방법. 모든 버전의 이력을 이진 파일로 저장하여 한 버전으로 쉽게 이동할 수 있습니다. "새 버전의 이진 파일을 이전 버전의 이진 파일로 덮어 쓰기"는 빠르지 만 여전히 오류가 발생하기 쉬운 수동 프로세스입니다. 그리고 때때로 "롤백이 실패하고 버그 대신 시스템을 사용할 수 없게 만드는 경우"를 요구합니다.

여기에서 아이디어가 부족한 부분에 대해 의견을 듣고 싶습니다. 간단한 릴리스 / 개발 프로세스 개선 조언을 공유 할 수 있다면 정말 좋습니다.

훌륭한 주제를 다루기 위해 +1. 우리가 "릴리스 초기 릴리스"를 개발할 때, 상황은 실질적인 속도로 올라가고, 모멘텀이 쌓이면서 (설명한 바와 같이) 많은 문제에 대처할 준비가되어 있지 않습니다. 사람들이 속도를 선한 일의 적이라고 생각하면 최악의 두려움입니다.

나는 이것에 대해 매우 제한된 문헌을 보았지만, 이것이 우리가 실천하는 것입니다.

1. 효과적인 버그 추적
버그 추적을보다 효과적으로 만드십시오. 우리가하는 일은 버그 및 체크 표시를 유지하는 것뿐만 아니라 닫을 때 "문제가 재현 가능한가?", "이것은 영구적 인 해결책입니까? 또는 작업 수정? ","문제의 근본 원인은 무엇입니까? " 이를 통해 지난 번에이 버그가 발견되었을 때 발생한 상황을 알 수 있습니다. 버그가 자주 반복되지 않도록하는 것이 중요합니다.

2. 주요 폴백 포인트 정의
우리는 모두 버그가 도착한다는 것을 알고 있으므로 가장 효과적인 폴백을 제공해야합니다. 우리는 언제 어디서나 가장 안정적인 방식으로 작동하는 가장 일반적인 릴리스를 마무리합니다 (이 경우 10의 약 1의 비율로). 총 릴리스 수는 많을 수 있지만 문제가 발생하는 경우 폴백은 거의 선택되지 않으며 더 이상 폴백 할 필요가 없습니다. 최고의 폴백을 아는 가장 간단한 방법 중 하나는 많은 문제없이 프로덕션에서 가장 오래된 릴리스를 확인하는 것입니다.

3. 위험하고 안정적이거나 작은 버그 수정 릴리스 구별
주요 알고리즘 변경이 있음을 알면 예상하지 못한 시나리오에서 버그가 발생할 수 있습니다. 이슈가 매우 작거나 이해가 잘되고 위험이 적은 경우가 있습니다. 동일한 릴리스에서 이러한 기능과 간단한 버그를 해결 하지 마십시오 . 항상 더 작은 버그를 먼저 수정해야하며 필요한 곳이면 어디든 가야합니다. 특수 기능 세트 에 대한 전용 릴리스를 최대한 활용하여 해당 기능을 폐기 할 수 있지만 다른 모든 중요 버그는 여전히 이전 릴리스에서 수정되어 사용할 수 있습니다.

4. 중요한 기능 개발을위한 브랜치
디자인에 영향을 미치는 변경 사항을 연관시키는 것은 브랜치에서 별도로 수행해야합니다. 작은 버그에 비해 큰 개발은 빨리 완료되지 않습니다. 여전히 사용되지 않는 기능과 관련된 '부분'작업이있는 중간 커밋을 도입하면 잠재적 인 버그 도입 영역입니다. 기능에 대한 전체 작업이 원자 적으로 완료되면 발생하지 않았던 버그-따라서 버그가 있으면 분기가있는 경우 해결할 필요가 없습니다.

5. 테마를 기반으로 한 릴리스 계획 항상
여러 가지 버그가 다른 릴리스로 제공되지만 유사한 모듈에 영향을주는 버그 (및 기능)를 구성하는 것이 가장 좋습니다. 릴리즈 로드맵을 항상 미리 준비하십시오. 버그는 계속해서 쏟아져 나옵니다. 좋은 릴리스에서 함께 버그를 모으는 최적의 버그 그룹을 갖기 위해 다른 대상 릴리스에 해당합니다. 유사한 버그가 결합되면 모순되는 시나리오에 대한 통찰력이 항상 향상됩니다.

6. 몇 개의 고객에게 먼저 새로운 릴리스를 확장합니다
. 우리의 경우, 먼저 두 사이트에서 테스트하고 다른 모든 사이트에는 요구가있을 때에 만 릴리스가 적용됩니다. 여러 번 (일부 또는 대부분의) 사용자는 안정 릴리스에서 다른 안정 릴리스로만 이동합니다.

7. 회귀 테스트
수집되는 버그 라인을 따라 회귀 슈트를 빌드하십시오. 또한 가능한 경우 릴리스 후보가 실제로 릴리스가되기 전에 테스트 할 최소 적격 기준이되는 중요한 버그 및 테스트를 가장 중요하게 표시하십시오.

8. 일시 정지 및 반영
많은 것들이 최고 속도로 진행될 때 약간의 휴식을 취할 시간이 있어야합니다. 잠시 멈추고 기능적으로 나아지지 않은 릴리스가 있어야합니다. 실제로 얼마 동안 석방 된 휴일이 있습니다. (길이는 주파수에 반비례합니다). 예를 들어 기능적 관점에서 새로운 것을 달성하지 못하지만 코드를 유지 관리하는 데 큰 도움이되는 이른바 "정리"릴리스가 있습니다. 이러한 릴리스의 대부분은 이전의 역사를 거의 기억하지 못하는 훌륭한 대체 요점입니다.

9. 아마도 가장 이상하게
생각되는 일이 자주 구현하기는 어렵지만 확실히 좋은 트릭입니다. 특정 모듈의 소유자를 교환하십시오. 사람들에게 코드 검토를 요청 받았을 때이 연습에서 많이 나오지 않습니다. 그러나 새로운 코드를 심각하게 다루어야 할 때 저자를 교체 할 때 잠재적 인 "나쁜"질병은 코드 오염을 시작하기 전에 훨씬 빨리 눈에 띄게됩니다. 물론 이렇게하면 속도가 줄어 듭니다. 그러나 이렇게하면 자주 사람들이 코드의 다양한 부분을 익히고 가르치는 것이 매우 어려운 전체 제품에 대해 배울 가능성이 있습니다.

10. 마지막
으로 화이트 보드로 자주 돌아가는 법을 배우십시오. 이 기능이 가장 초기 디자인의 일부인 것처럼 다시 생각 하면, 당시 디자인을 어떻게 생각했을까요? 때때로 증분 작업의 가장 큰 과제는 우리가 처음 구축 한 기능의 순서에 너무 제약을 받아 기본으로 돌아갈 수 없다는 것입니다. 비결은이 새로운 기능이나 시나리오를 수용하기보다는 일반화하는 방법을 계속 보는 것입니다. 이를 위해서는 디자인이 최신 상태를 유지해야하며 드로잉 보드로 자주 돌아가는 경우에만 발생합니다. 또한, 차세대 프로그래머가 참여할 때, 단지 패치를 붙이는 것이 아니라 사고 탱크의 일부가됩니다.

편집
11. 해결 방법 및 설계 격차를 추적하십시오.
우리는 종종 버그를 수정하고 프로덕션 환경에서 릴리스하도록 타임 라인의 압력을 받고 있습니다. 그러나 버그가 디자인 수준에있을 때는 변경해야 할 사항이 많지만 사람들은 기한을 맞추기 위해 일부 바로 가기로 수정하는 경우가 많습니다. 이다 OK . 그러나 솔루션에 대한 여러 가지 해결 방법이 증가함에 따라 코드가 취약 해집니다. 이미 얼마나 많은 설계 격차가 발생했는지 특별한 추적을 유지하십시오. 일반적으로 프로젝트 관리자와 타임 라인을 협상 할 때는 생산을 절약하기 위해이를 짧은 시간에 제공해야하지만 생산 시간도 단축해야합니다. 영구적 인 솔루션을 얻기위한 타임 라인 및 리소스.

나는 작은 dev 팀에서도 일하고 ​​(우리 중 2 명만) 우리는 당신이 언급 한 비슷한 문제를 경험했습니다. 우리에게 주된 문제는 우리가 별도의 작업을 수행하는 경향이 있으며 작업 / 기능을 완료하고 테스트하고 (개발자 만 테스트 한) 신속하게 릴리스하기에는 너무 일반적이되었다는 것입니다. 이로 인해 사용자는 테스트에서 쉽게 찾아 낼 수있는 작은 버그를보고하는 작은 릴리스가 많이 생겼습니다.

프로세스를 개선하기 위해 Kanban 보드 를 소개했습니다 . 보드는 시작하기가 매우 간단하고 몇 개의 열만있었습니다 (화이트 보드, 색인 카드 및 컬러 자석을 사용한 설정).

백 로그 | 해야할 일 | 끝난

그러나 이것은 실제 프로세스를 반영하도록 빠르게 발전했습니다.

백 로그 | 개발 | 개발자 테스트 | UAT | 완료 | 출시

이사회와 함께 각 작업 / 기능을 다른 개발자 (및 기능을 구현 한 개발자)가 테스트해야한다는 규칙이 있습니다. 따라서 카드가 '완료'열에 도달 할 때까지 최소 2 명의 개발자가 테스트해야하며 사용자 승인 테스트를 거쳐야합니다.

Kanban을 사용하면 많은 다른 이점이 있습니다. 우리에게는 의사 소통이 개선되었고 우리가 각 과제에 어느 정도 참여할 때 지식을 공유하는 데 도움이되었습니다. 또한 릴리스 / 완료 할 준비가 된 작업 / 기능을 정확히 볼 수 있으며 다른 탁이 곧 완료 될 경우 릴리스를 보류 할 수 있으므로 릴리스 프로세스도 개선되었습니다. 팀 외부의 사람들을 위해 이사회는 우리가 예약 한 작업, 현재 진행중인 작업 및 최근에 릴리스 된 작업을 확인하는 빠른 참조 역할도합니다.

옆으로, 우리는 유색 자석 (개발자 당 하나)을 사용하여 현재 작업중인 카드에 플래그를 지정하지만, 또 다른 옵션은 개발자 당 하나씩 수영 레인 (행)을 추가하고 관련 수영 레인에 Kanban 카드를 배치하는 것입니다. 다시 한 번 말하지만, 각 개발자가 현재 무엇을하고 있는지 확인하기위한 빠른 참조로 도움이됩니다.

내가 찾은 다른 링크 :

Kanban, 소프트웨어 개발에 적용 : Agile에서 Lean까지

소프트웨어 공학을위한 Kanban 시스템-비디오

잘하면 Kanban이 귀하의 질문에 포인트 1을 제시 할 것입니다. 코드 검토와 관련하여 개발 테스트 단계에서이 작업을 수행하므로 UAT로 이동하기 전에 검토 후 필요한 모든 변경 사항을 다시 테스트해야합니다. 롤백은 환경에 따라 다르지만 현재 파일의 이름을 바꾸고 중앙 서버에서 새 파일을 복사하는 배치 파일을 사용하여 응용 프로그램 파일을 터미널 서버에 배포하며 중앙 위치에 백업 (이전 파일)을 배치하여 상당히 쉽게 롤백 할 수 있습니다. 스크립트를 다시 실행하십시오.

프로세스 품질에 소프트웨어의 품질에 영향을 미치는 문제가 있음을 이미 알고 있으며,이 질문이 다양한 답변을 불러 일으킬 것이지만, 소프트웨어 엔지니어링 주제를 살펴보고 주요 개발자들은 그 분야에서 점점 더 많은 일을하고 있습니다. 나는 당신이 시작하기 위해 몇 가지 좋은 자료를 읽기 시작하는 것이 좋습니다. 생각 나는 몇 가지 :

• Mary와 Tom Poppendeick의 Lean Software Development 는 "폐기물"을 식별하는 방법에 대해 배우고 프로세스를 더 얇고 효율적으로 변경하는 방법에 대해 배우려는 사람들에게 유용한 정보를 제공합니다.
• Dan Pilone과 Russ Miles의 Head First Software Development 는 언뜻보기에는 "인형 용"책 중 하나와 약간 비슷하지만 혼란스러운 프리젠 테이션 스타일을 약간 지나쳐서 소프트웨어 엔지니어링의 기본 사항과 관련된 대부분의 정보를 포함합니다. Test Driven Development에 대한 간단한 글을 썼습니다.
• BDD 소개 는 행동 기반 개발에 들어가는 Dan North의 페이지이거나 BDD Wiki를 선호 할 것 입니다. 이것들은 BDD에 대한 초보자 참조이며 아마도 당신을 돕기 위해 도구와 프레임 워크를 조사하고 싶을 것입니다. 이해해야 할 중요한 것은 BDD가 효과적으로보다 높은 개념 수준으로 취해지는 TDD라는 것입니다. 스펙에 대해 생각할 때 테스트에 대해 생각하고 스펙을 작성할 때 사용하는 것과 동일한 언어로 테스트 할 수 있습니다. 프레임 워크는 일반적으로 다른 단위 테스팅 프레임 워크와 통합되므로 테스트에서 BDD 구문의 이점을 반드시 얻지 못할 경우 두 가지 이점을 모두 누릴 수 있습니다.
• Wikipedia의 Agile Software Development Article 은 애자일 소프트웨어 개발 에 대한 좋은 입문서이며, 개발 커뮤니티의 존경받는 사람들이 제공하는 여러 유용한 참조 및 기사 링크를 제공합니다.

업무 방식을 향상 시키려면 자신이 완전히 열린 마음을 가질 수 있도록해야하며, 발견 할 수있는 특정 개념에 집착하지 않고 자신이하는 일을 개선하기 위해 안락 지대 밖으로 나아갈 수 있어야합니다. 더 편안하게 걸 수 있습니다. 개인적인 경험으로 말하면, 이것은 아마도 가장 어려운 일이거나 다른 사람들을 격려하는 것입니다.

적극적으로 변화를 모색하고 있다고 생각하더라도 최선의 변화는 어렵습니다. 따라서 제가 실제로 줄 수있는 최선의 조언은 수년에 걸쳐 개발 된 다양한 민첩한 방법론을 살펴보고 실습에 익숙해 지도록하는 것입니다 가장 중요한 것으로 간주되는 (예 : 단위 테스트, 지속적인 통합, 리팩토링 등) 사용자와 팀이 가장 편안하게 느끼는 방법론을 선택하십시오. 일단 결정을 내린 후에는 관행과 개발 프로세스를 조정하여 팀이 선호하는 방식에 맞게 팀이 선호하는 방식에 맞도록 조정하고 개발 프로세스를 조정하여 팀이 최고의 가치를 창출 할 수 있도록하십시오. 최소한의 낭비. 드디어,

공정 조정이 필요하다고 생각하지만 툴 체인이 사용자의 요구를 충족시키지 못하는 것이 우려된다면 개선을 기대할 수 있습니다. 최소한 지속적인 통합 통합 제품 (예 : Continuum, Cruise Control 또는 Hudson)과 이슈 추적 시스템 (예 : Jira 또는 Redmine)은 일부 빌드 및 릴리스 프로세스를 자동화하는 데 도움이되는 우선 순위 여야합니다. 버그 및 기능 요청을 확인합니다.

실제로 프로세스가 얼마나 RAD 이건 관계없이 팀에 "올바른"작업을 수행하는 데 시간을 투자하지 않으면 문제는 시간이 지남에 따라 계속 커지고 가용 시간에 대한 인식은 그에 따라 축소하십시오. 시간이 많이 걸리는 상황에서는 큰 변화가 일반적으로 문제가되지 않지만, 이상적인 방법론에 대한 팀의 비전을 향해 아기 발걸음을 내딛을 수 있도록 시스템을 마련하기 위해 약간의 "흔들리는 방"을 만들어보십시오.

결함에 대해들을 때마다 첫 번째 질문은 결함의 시작 위치와 결함이 발견 및 제거되는 위치에 관한 것입니다. 결함 제거 효율 은이를 측정하고 추적하는 좋은 방법입니다. 결함이 어디에서 발생하는지 알고 해당 단계에서 프로세스를 개선하기 위해 노력함으로써 프로젝트의 시간과 비용을 줄일 수 있습니다. 결함을 주입 지점에 더 가깝게 고정하는 것이 더 저렴하다는 것이 잘 알려져 있으므로 결함이 어디에서 왔는지 알게되면 활동 변경을 검토하여 해당 단계를 개선 할 수 있습니다.

결함의 출처에 대한 정보가 있으면 적용하려는 기술과 기술을 정확하게 볼 수 있습니다. 요구 사항, 디자인 및 코드, 자동화 된 테스트, 정적 분석, 지속적인 통합 및보다 광범위한 사용자 중심 테스트에 대한 검토는 결함을 생성하는 단계에 따라 살펴 봐야 할 옵션입니다.

코드 검토에 대한 욕구를 확장하려면 모듈의 우선 순위와 위험에 따라 다른 수준의 코드 검토도 고려해야합니다. 위험이 낮고 우선 순위가 낮은 모듈은 코드 검토가 전혀 필요하지 않거나 다른 개발자가 직접 코드를 읽고 주석을 제공하는 간단한 데스크 검사가 필요할 수 있습니다. 다른 코드 검토 기술에는 여러 개발자와의 쌍 프로그래밍, 연습, 비평 및 검사가 포함됩니다.

롤백의 목적으로, 일종의 스크립트를 사용하여 프로세스를 자동화하여 오류가 발생하기 쉽고 빠릅니다. 완벽한 세상에서는 롤백 할 필요가 없도록 선적 된 제품의 품질을 높이고 싶습니다.이를 달성 할 수 있습니다. 그러나 능력을 갖는 것이 좋은 생각 일 수 있지만 가능한 한 고통스럽지 않게하십시오.

다른 사람들이 지적했듯이 회귀 테스트 를 추가 하면 앞으로 동일한 결함이 나타나는 것을 피할 수 있습니다. 그러나 새로운 결함이 발생 하면 사전 조건, 사후 조건 및 클래스 및 메소드의 불변량을 지정하는 어설 션 (일명 계약)을 코드 에 추가 해야 할 때가 있습니다.

예를 들어, 메소드가 10에서 25 사이의 숫자 만 허용하는 클래스가있는 경우 (이를 사전 조건이라고 함) 메소드 시작시 어설 션 명령문을 추가합니다. 이 어설 션이 실패하면 프로그램이 즉시 중단되고 해당 실패로 이어진 일련의 메소드를 따라갈 수 있습니다.

파이썬, PHP 및 기타 프로그래밍 언어는 동적으로 입력되며 메소드에 많은 조건을 추가하지 않습니다. 무언가가 작동하는 데 필요한 것은 특정 방법을 구현하는 것입니다. 나는 당신이 당신의 방법에 더 많은 조건이 필요하다고 생각합니다. 메소드가 실제로 해당 환경에서 작동하는지 확인하고 정의해야합니다.

C / C ++ 프로그램의 경우 메모리 할당 테스트에 어설 션을 추가하면 프로그램의 메모리 누수 수를 줄이는 데 매우 도움이된다는 것을 알았습니다.