릴리스 주기가 계속 멈추는 이유

저희 회사에는 매달 업데이트되는 10개의 프로덕션 앱이 있습니다. "릴리스 개발자" 또는 "릴리스 엔지니어"는 매 릴리스마다 팀 내에서 순환 근무합니다.

최소 권한 원칙(PoLP)을 준수하기 위해, 릴리스 개발자에게 필요한 경우에만 배포 권한을 부여하고자 합니다. 따라서 모든 릴리스 전에 적절한 담당자에게 프로덕션 배포 권한을 부여하고, 릴리스 후에는 해당 권한을 취소할 수 있어야 합니다.

프로젝트 역할 할당 Mendix

In Mendix 개발자에게 프로젝트에 대한 액세스 권한을 부여하려면 다음을 수행하세요. 특정 역할2025년 XNUMX월부터 몇 가지 업데이트가 이루어졌습니다.

• 회사 관리자만 역할을 정의할 수 있습니다.
• 이제 역할에 퍼블릭 클라우드 환경 권한이 포함될 수 있습니다.
• 당신은 또한 사용할 수 있습니다 프로젝트 API 특정 역할을 가진 프로젝트에 팀원을 배정하다.

이 릴리스 주기 예제에서는 두 가지 역할을 설정해야 합니다. 일반 개발자를 위한 역할 하나와 프로덕션에 배포할 권한이 있는 릴리스 개발자를 위한 역할 하나입니다.

일반 개발자 역할 생성

먼저 일반 개발자 역할을 만들어 보겠습니다. 제어 센터 를 클릭하십시오 사람들 메뉴 섹션을 열고 역할 및 권한 안내

1 – 프로젝트 역할 세부 정보 섹션 편집

이미 정규가 존재하기 때문에 개발자 선택할 수 있는 역할이 있다면, 먼저 해당 역할을 편집하는 것부터 시작하겠습니다. 첫 번째 단계는 이 역할에 부여될 권한을 설정하는 것입니다(아래 스크린샷 참조).

2 – 프로젝트 권한 편집

설명을 마치면 클릭하세요. 다음 이 개발자 역할에 대한 프로젝트 권한을 설정하려면 다음을 참조하세요. 고려해야 할 사항은 다음과 같습니다.

• 프로젝트 관리자 권한: 이 권한은 (시스템) 스크럼 마스터 역할에만 할당하는 것이 좋습니다. 이 권한을 통해 사용자는 팀원 권한을 관리하고 프로젝트 설정을 변경할 수 있습니다. 이는 엄격하게 관리되어야 하는 강력한 기능입니다.
• 팀 서버 권한: 이 권한은 개발자가 작업을 커밋할 수 있도록 팀 서버에 대한 접근 권한을 부여합니다. 모든 개발자 역할에 필수적입니다.
• 계획 및 피드백: 개발자는 자신에게 할당된 사용자 스토리를 보고 작업하려면 이 권한이 필요합니다.
• 회원 초대: 이 권한은 (시스템) 스크럼 마스터 역할로 제한하는 것이 좋습니다. 이 권한을 사용하면 사용자가 프로젝트에 새 멤버를 초대하고 역할을 할당할 수 있으므로 최소한으로 유지하는 것이 좋습니다.

3 – 비생산 환경 권한 설정

액세스 권한

먼저, 이 역할이 비프로덕션 환경에 액세스할 수 있는지 여부를 선택합니다.

• 개발자 역할의 경우 일정 수준의 액세스 권한이 필요합니다.
• 다른 역할의 경우 이를 설정할 수 있습니다. 액세스 할 수 없음즉, 사용자는 비프로덕션 환경에서 어떠한 권한도 받지 못합니다. 해당 역할에 대해서는 이 섹션의 나머지 부분을 건너뛸 수 있습니다.

권한 관리: 고정 대 사용자 지정

이 설정은 비프로덕션 환경 권한이 적용되고 관리되는 방식을 제어합니다.

고정

역할에 고정 권한이 사용되는 경우, 역할 정의에 나열된 권한이 자동으로 적용됩니다. 이 역할이 할당된 사용자는 여기에 정의된 권한을 그대로 받게 되며, 프로젝트에 참여하는 사람들은 클라우드 권한 관리 이 역할이 있는 멤버의 권한을 수동으로 변경할 수 없습니다.

간단히 말해, 이는 회사 관리자가 프로젝트에서 이 역할을 맡은 멤버가 여기에 나열된 권한을 정확히 가지고 있다는 것을 확신할 수 있다는 것을 의미합니다.

관습

사용자 지정 권한을 사용하는 경우 역할 자체가 액세스를 결정하지 않습니다. 권한은 수동으로 할당해야 합니다. Mendix 적절한 권한이 있는 사람이나 API를 통해 설정한 개발자 포털입니다.

중요: 사용자에게 이미 권한이 있는 경우(예: 스크럼 마스터), 사용자 지정 권한이 있는 역할을 할당해도 권한이 자동으로 취소되지 않습니다. 기존 권한은 수동으로 또는 API를 통해 변경할 때까지 유지됩니다.

가능하면 고정 권한을 사용하는 것이 좋습니다. 고정 권한은 완벽한 중앙 제어 기능을 제공하고 예상치 못한 권한 공백을 방지합니다. 사용자 지정 권한은 배포를 허용하는 등 여러 비운영 환경 간에 구분이 필요한 경우에만 사용하세요. 개발 Test , 하지만 수용됨을 느낍니다.

개발자 역할의 경우, 개발자에게 권한을 직접 관리하는 기능 외에도 비프로덕션 환경에 대한 모든 권한을 부여합니다.

4 – 프로덕션 환경 권한 설정

프로젝트 역할 편집의 마지막 단계에서는 프로덕션 환경 권한을 구성합니다. 프로덕션 환경의 모든 변경 사항에는 2단계 인증이 필요하므로, 회사 관리자는 진행하기 전에 계정을 인증해야 합니다.

인증이 완료되면 적절한 권한을 설정할 수 있습니다. 개발자는 프로덕션 환경에서 앱의 작동 상황을 모니터링할 수 있어야 하므로, 모니터링 권한을 부여하는 것이 좋습니다.

이로써 일반 개발자 역할이 설정되었습니다. 이제 개발자가 프로젝트에서 이 역할을 할당받으면 비운영 환경에 즉시 배포하고 운영 환경에서 모니터링 정보를 확인할 수 있습니다. 이전에는 스크럼 마스터나 기술 담당자가 직접 구성해야 했던 작업입니다. 생산성이 크게 향상되었습니다!

릴리스 개발자 역할 생성

다음으로, 프로덕션에 배포하는 데 특별히 사용되는 릴리스 개발자 역할을 정의합니다.

이 역할은 꼭 필요할 때만 사용하도록 장려하고 배포 후에는 반드시 취소되도록 하기 위해 매우 제한적으로 운영될 예정입니다. 따라서 이 역할을 맡은 팀원은 정상적인 업무를 계속하려면 정규 개발자 역할을 다시 부여받아야 합니다.

즉..

• 프로젝트 권한이 없습니다
• 비생산 환경에 액세스할 수 없습니다.

…그리고 다음의 프로덕션 환경 권한만:

• 배포 - 프로덕션에 릴리스
• 백업 - 배포하기 전에 백업을 생성합니다.
• 모니터링 - 모든 것이 원활하게 진행되었는지 확인하기

이러한 역할을 적용하는 방법

개발자에게 프로젝트 역할을 할당하는 방법에는 여러 가지가 있습니다.

• 스크럼 마스터는 개발자에게 역할을 추가하거나 초대할 수 있습니다.
• 회사 관리자는 개발자에게 역할을 추가하거나 초대할 수 있습니다.
• 프로젝트의 API는 개발자를 프로젝트에 역할로 추가하는 데 사용됩니다.

Gaby Gable과 같은 단일 개발자가 여러 앱을 출시해야 하는 경우 회사 관리자는 다음 단계에 따라 앱을 할당할 수 있습니다. 릴리스 개발자 필요한 프로젝트 전반에 걸친 역할: 제어 센터, Gaby를 검색하세요 회원 목록:

그녀의 이름을 클릭하면 그녀가 참여한 모든 앱 목록을 볼 수 있습니다.

앱 이름을 클릭하여 엽니다. 앱 세부 정보 패널. 이동 회원 페이지를 확인하시기 바랍니다.

클릭하면 회원 관리, Gaby의 역할을 변경합니다 릴리스 개발자.

배포해야 하는 각 앱에 대해 이 단계를 반복합니다. Gaby의 역할이 업데이트되면 Gaby는 할당된 모든 앱에 배포할 수 있는 권한을 갖게 됩니다.

릴리스가 완료되면 회사 관리자는 동일한 프로세스를 사용하여 Gaby를 원래 역할로 되돌릴 수 있습니다. 이렇게 하면 불필요한 프로덕션 권한 없이 일반 개발자 액세스 권한으로 돌아갈 수 있습니다.

특정 환경에 대한 임시 권한 부여

경우에 따라 팀원에게 모든 프로덕션 또는 비프로덕션 환경이 아닌 하나의 환경에만 임시 액세스 권한을 부여해야 할 수 있습니다. 고정 권한이 있는 역할은 이러한 수준의 세분성을 지원하지 않으며, 프로덕션 또는 비프로덕션 범주의 모든 환경에 권한을 적용합니다.

그렇다면 다음과 같은 여러 프로덕션 환경이 있는 경우는 어떻게 됩니까? 생산 생산2그리고 당신은 단지에 임시 액세스 권한을 부여하려고 합니다. 생산?

이 사용 사례에서는 다음을 정의할 수 있습니다. 개발자 사용자 정의 역할. 일반 개발자와 동일한 권한이 있지만, (비)프로덕션 권한은 프로젝트 역할에 포함되지 않습니다. 단, 해당 권한은 수동 또는 API를 통해 설정할 수 있습니다.

이를 처리하는 방법은 다음과 같습니다.

비생산 권한과 생산 권한을 모두 설정하세요. 관습.

Gaby가 현재 고정된 권한을 가진 역할을 가지고 있다고 가정해 보겠습니다. 이는 Gaby의 환경 접근 권한이 잠겨 있어 스크럼 마스터나 기술 담당자가 변경할 수 없음을 의미합니다.

이것을 볼 수 있습니다 Mendix 포털 앱의 권한 탭 생산 환경 - 그녀의 권한은 읽기 전용으로 표시됩니다.

Gaby의 권한을 편집 가능하게 하려면 그녀에게 다른 프로젝트 역할을 할당하세요. 이 경우에는 다음과 같습니다. 개발자 사용자 정의.

이 새로운 역할은 일반 개발자와 동일한 프로젝트 수준 권한을 갖습니다. 하지만 환경 권한이 사용자 지정되므로 환경 액세스 관리 권한이 있는 팀원(예: 기술 담당자)이 직접 권한을 업데이트하거나 Deploy API를 사용하여 권한을 업데이트할 수 있습니다.

이를 통해 다른 모든 환경에 대한 제어를 손상시키지 않고도 단일 환경에 대한 임시 액세스 권한을 부여할 수 있는 유연성이 제공됩니다.

유연성과 통제력의 균형

사용자 지정 역할은 보안 모델을 약화시키지 않고 단일 환경에 대한 임시 액세스 권한 부여와 같은 예외를 유연하게 처리할 수 있도록 해줍니다. 반면, 고정 역할은 모든 프로젝트와 환경에 걸쳐 일관되고 중앙화된 권한을 적용하려는 경우에 이상적입니다.

두 가지 접근 방식을 신중하게 결합하면 핵심 보안 모범 사례인 최소 권한 원칙(PoLP)을 준수할 수 있습니다. 즉, 모든 팀원은 업무 수행에 필요한 권한만 부여받으며, 그 이상도 그 이하도 아닙니다. 고정 역할을 기본값으로 사용하고 예외적인 상황에 대비하여 사용자 지정 역할을 예약하면 위험을 최소화하는 동시에 릴리스 프로세스를 원활하고 효율적으로 유지할 수 있습니다.