3 개발 환경에서 기능 모듈을 사용하는 방법은 무엇입니까?


19

프로젝트를 작업하면서 Feature 을 많이 사용하면 때로는이 응용 프로그램에 3 명의 개발자가 있습니다.

우리는 몇 가지 접근법을 시도했지만 git 브랜치를 병합하면 서로의 기능 변경 사항을 종종 '덮어 쓰기'하는 것처럼 보입니다. 기능 모듈이 깨져서 사용하기가 어려워지는 것처럼 보입니다.

기능은 실제로 프로젝트에서 하나를 구성하기위한 훌륭한 시간 절약 도구이며이를 해결할 수있는 방법이 있다고 확신합니다.

충돌 및 덮어 쓰기의 위험을 줄이는 워크 플로 또는 절차가 있습니까?

기능에 대한 단서는 환영합니다.

답변:


20

땅에 오신 것을 환영합니다 F는 eatures C를 onfiguration M의 일명 관 리 FCM ! 이는 Drupal 버전 8에 도입 된 Configuration Management 가 아니라 Features 기능 에 관한 것이 아닙니다 . 대신의 특별한 경우이다 S oftware C onfiguration M 관 리 , 일명 SCM은 . 대부분 기능 은 코드 생성기로 간주 될 수 있지만 생성 된 코드는 여러 환경을 통해 마이그레이션해야합니다. 자세한 내용은 계속 읽으십시오.

1-기능 사용의 장단점

기능 사용의 장점

  • Drupal 개발 사이트에 적용된 변경 사항을 수동 배포 대신 하나 이상의 대상 Drupal (사전) 프로덕션 사이트에 자동으로 배포합니다.
  • Drupal 개발자 / 사이트 빌더간에 진행중인 Drupal 개발을 공유 (배송) 할 수 있습니다 (예 : 뷰 전문가가 생성 한 일부 뷰를 Drupal Themer가 다른 개발 사이트에서 작업하여 해당 뷰를 테마로 볼 수 있도록).
  • 기능 (개발 사이트)에서 생성 된 코드 사본 을 선택된 대상 (사전) 프로덕션 사이트 로 배송하기 위해 GIT 및 Drush와의 통합이 우수 합니다.

기능 사용의 단점

  • 기능 충돌 방지 및 / 또는 기능 종속성 관리 가 어려울 수 있습니다!
  • 기존 (프로덕션) 사이트에서 기능 을 사용하기가 쉽지 않습니다 .
  • 기능 모듈을 설치 / 활성화하는 것은 쉽지만 (단지 모듈) 기능을 올바르게 사용하는 방법을 배우는 것은 큰 도전입니다.

2-피처 패키징 기술

기능 을 사용하면 기능 의 내용을 패키지화 (구성)하는 방법을 상상할 수 있습니다. 여기에 사용할 수있는 기술이 있습니다.

하나의 슈퍼 기능

이것은 매우 간단한 패키징 기술입니다. 모든 것이 단일 기능으로 함께 패키징됩니다 (일부는 "신"기능이라고합니다). 쉽고, 매우 앞선 것처럼 보입니다. 그러나이 기술은 또한 "아래에 설명 된대로" "충돌"을 야기합니다.

"Drupal distribution"을 작성할 때이를위한 좋은 유스 케이스 인 것으로 보입니다. "Drupal distribution"은 모든 사용자가 동일한 모듈, 구성 등을 사용하는 것으로 가정합니다. 그러나 그러한 배포가 여러 웹 사이트 기능으로 구성되어있는 경우 "기능"...), 이러한 기능을 아래 설명 된대로 여러 기능으로 분할하는 것이 더 적절 해 보입니다.

웹 사이트 기능 기반

이 패키징 기술은 다음과 같이 웹 사이트의 각 기능에 대해 별도의 기능을 만듭니다.

  • 기능 A = " * 갤러리 "를 구현하십시오 .
  • 기능 B = " * Blog "를 구현합니다 .
  • 기능 C = " * 이벤트 캘린더 "를 구현하십시오 .

Drupal 관리 섹션 기반

이 패키징 기술은 다음과 같이 사이트를 만드는 데 사용되는 Drupal 웹 사이트의 각 주요 관리 섹션에 대해 별도의 기능을 만듭니다.

  • 모든 필수 모듈은 기능 A에 포함되어 있습니다.
  • 모든 기본 필드 정의는 기능 B에 포함되어 있습니다.
  • 모든 콘텐츠 유형은 기능 C에 포함되어 있습니다.
  • 모든 권한은 기능 D에 포함되어 있습니다.
  • 모든 역할은 기능 E에 포함되어 있습니다.
  • 모든 변수는 피처 F에 포함됩니다.
  • 모든 (사용자 정의) 는 피처 G에 포함됩니다.
  • 모든 (사용자 정의) 규칙 은 기능 H에 포함되어 있습니다.
  • 기타.

위의 목록은 사실상 무제한입니다. 결국 당신이 그것을 원한다면 각 Drupal 관리자 메뉴 옵션에 대해 하나의 기능으로 생각할 수도 있습니다.

IMO는 패키지 기능에 가장 권장되는 방법이기도합니다.

3-기능 및 / 또는 GIT에서 충돌 가능성 감소

필드를 재사용하지 마십시오

여러 컨텐츠 유형 중 필드를 재사용하면 약간의 충돌이 발생하는 것 같습니다. 예를 들어 컨텐츠 유형 A에는 machine name을 가진 필드가 있으며 field_somefield, 이는 머신 이름이 동일한 컨텐츠 유형 B의 필드로 사용 field_somefield되지만 다른 필드 유형 및 / 또는 다른 다른 필드 설정으로도 사용됩니다.

콘텐츠 유형간에 필드를 재사용하지 않으면이 문제가 발생하지 않습니다. 랩핑 정보 아키텍처 및 문서 표에 나와있는 " Drupal의 상대성 모델 "에 대한 기사의 일부인 컨텐츠 유형 및 필드의 머신 이름에 대한 흥미로운 이름 지정 규칙을 살펴보십시오 . 이에 대한 자세한 내용은 " 데이터베이스 중심의 관점에서 컨텐츠 (유형)를 어떻게 모델링합니까? "에 대한 나의 대답을 참조하십시오 .

누가 무엇을 하는가에 따라 기능 분할

여러 사람이 단일 사이트에서 작업하는 경우 누가 무엇을 작업하는지에 따라 기능을 구성하여 (= 별도 만들기) 충돌의 양을 줄일 수 있습니다. 이 예는 다음 예와 같습니다.

  • 는 기능 A에 들어가고
  • 규칙 은 기능 B에 적용 됩니다.
  • 기능 C에 차트 가 들어가고
  • Theming 에 관한 모든 것은 기능 D에 있습니다.

4-권장 Drupal 환경

위의 모든 것은 기능 사용을 용이하게하는 데 도움이됩니다 . 그러나 작업이 예상대로 (디자인 된) 작동하게하려면 기본적으로 다음과 같은 이유로 적절한 환경 세트 (논리적으로 관련된 Drupal 웹 사이트)가 있어야합니다.

  • 여러 기능에서 제공하는 병합 기능.
  • 갈등을 예측하고 해결합니다.
  • 충돌이없는 것으로 인증 된 모든 병합 된 기능의 최종 사용자 테스트.

이상적인 세계에서 논리적으로 관련된 Drupal 웹 사이트는 다음과 같이 구성하고 사용해야합니다.

  1. 개인 개발 사이트 -각 웹 사이트 개발자에게는 별도의 개발 사이트가 있습니다. 개발의 일부를 다른 사람과 공유 할 준비가되면 적절한 기능이 작성되어 스테이징 환경으로 제공됩니다.
  2. 샌드 박스 사이트 -단일 기능의 완전성을 단위 테스트하는 데 사용되는 Drupal 코어 만 포함하는 Drupal 환경입니다. 실수로 기능에 예기치 않은 종속성이있는 경우 (예 : 기능이 의존하는 일부 모듈 (샌드 박스에서 활성화되지 않은 모듈))에는 종속성이 명확 해집니다.
  3. 준비 사이트 -여기에서 하나 이상의 기능 (개발 사이트에서 생성)이 제공됩니다. 일부 프로덕션 문제에 대한 일부 핫픽스 일 수도 있고 웹 사이트의 새 릴리스에 대한 모든 개발이 통합 된 것일 수도 있습니다. 여러 기능간에 충돌이 발생하면 이것이 처음 표시되는 환경이며 어떻게 든 해결해야합니다.
  4. QA 사이트 -스테이징 환경이 안정적인 것으로 간주되면 관련 기능으로 이동하여 QA 테스트, 승인 테스트, 볼륨 테스트 등에 사용할 수있는 상위 레벨에서도 사용할 수 있습니다. 추가 변경 사항이있을 경우 매우주의해야합니다. 이러한 변경으로 인해이 환경에서 이미 완료된 모든 사전 테스트 노력이 무효화 될 수 있습니다.
  5. 섀도 프로덕션 사이트 -실제 프로덕션에서 활성화를 준비하려면 먼저 실제 프로덕션 환경의 복사본 (그림자)으로 간주되는 환경에 관련 기능을 추가로 홍보 할 수 있습니다. 마이그레이션 프로세스 중에이 시점에서 여전히 문제가 발생하면 이전 단계 중 일부를 되돌릴 수있는 위험 신호입니다. 수정 한 후 관련된 모든 당사자가 변경 사항을 승인 할 때까지 다시 시도하십시오.
  6. 생산 현장 -모든 이전 단계를 완료 한 경우이 단계는 자체 설명이 필요하며 매우 쉽습니다. 필요에 따라 단일 사이트이거나 Drupal의 다중 사이트와 동등한 사이트 일 수 있지만 관련된 모든 사이트는 모든 기능의 동일한 버전을 실행하고 있습니다.
  7. Baseline Site- 필자의 경험에 따르면이 유형의 사이트가 사용되는 Drupal 구현은 많지 않습니다. 프로덕션 사이트의 복사본이지만 Drupal 개발자, 테스터 등이 사용할 수 있으며 프로덕션 사이트의 모양을 확인하거나 사용자 교육 등을 수행하는 데 사용할 수 있습니다. 주기가 시작되면 영향을받는 (변경이 필요한) 사이트의 구성 요소는이 기본 사이트를 입력으로 사용하고 개인 개발 사이트 를 대상으로하여 "어떻게 복사"해야합니다 .

분명히 Drupal 사이트 유형의 위 인벤토리는 이상적인 세계와 같습니다. 개발 팀의 규모 및 / 또는 예산을 만들고 유지 관리하는 데 사용할 수있는 예산에 따라 모든 예산을 사용할 수있는 것은 아닙니다. 이 인벤토리는 SCM 영역에서 모범 사례를 모델로하며 대부분의 모든 거대 / 글로벌 기업 (은행, 항공사 등)에서 사용됩니다.

5-관련 모듈

강한 팔

스트롱 모듈은 모듈 기능 (변수의 설정을 저장하는 모듈) 변수를 내보낼 수있다.

노드 익스포트

노드 수출 모듈 수출 노드에 사용자를 허용하고 다른 드루팔 설치로 가져옵니다.

역할 수출

역할 내보내기 모듈 역할 machine_names를 가질 수 있으며 여기서 machine_name의 기반으로 고유 한 역할 ID (RID)를 생성한다. 기능을 사용 하여 역할을 내보내고 다른 사이트에서 가져 오면 완전히 제거 할 수 있습니다.

추방

추방의 기능 모듈은 완전히가 UI와 기능 수출을 갖추고에서 개별 기능 컴포넌트를 제외 수 있습니다. 다음은 프로젝트 페이지에서 인용 한 것입니다.

 이 모듈은 내보내기를 원하지 않는 기능 구성 요소가있는 경우에 유용합니다. 사이트 구축 또는 배포 기능을 사용하는 경우 누군가 cron_last 또는 update_last_check와 같은 타임 스탬프 변수를 실수로 내보내는 문제가 발생했을 수 있습니다. 내보내려는 나머지 사이트 권한에 걸리지 않도록 개발자 모듈에 대한 권한을 제거 할 수도 있습니다. 삭제 된 항목은 기능 모듈이나 다른 기능 모듈에 표시되지 않으므로주의해서 사용하십시오. 내보낼 수없는 기능의 중앙 목록은 https://www.drupal.org/node/2400531을 참조 하십시오.

모듈은 블록을 내보낼 수 있습니다. 다음은 프로젝트 페이지에서 인용 한 것입니다.

Bean을 새로운 유형 (노드와 비교할 때 내용 유형 임)을 제공하는 방법으로 생각하면 필요한만큼 많은 블록을 생성하기 위해 컨텐츠 추가 인터페이스를 제공합니다 (아래 스크린 샷 참조). 그런 다음 다른 블록처럼 빈 컨텐츠를 사이트 주변에 배치 할 수 있습니다.

이 모듈은 UUIDUUID 기능 통합 모듈 과 함께 사용할 수도 있습니다 . 이 모듈은 D7부터 시작되었지만 Drupal 8 코어에 이미 포함되어 있습니다. 비디오 자습서 Drupal Bean 모듈 학습서-Bean Admin UI 사용 은이 모듈의 기능과 사용자가 코딩 할 수있는 사이트 빌드 기술 만 사용하여이 모듈의 기능을 실제로 이해하기위한 훌륭한 소개를 제공합니다.

서식지

서식지 A가에 모듈이 가장 적합한 특징 기반의 워크 플로우를. 다음은 프로젝트 페이지에서 인용 한 것입니다.

다중 환경 설정 (예 : prod, test, dev, local)에는 특정 환경에서 항상 활성화 또는 비활성화하려는 일부 모듈이 있습니다. 데이터베이스를 동기화 할 때마다 동일한 모듈을 다시 활성화 / 비활성화해야합니다. 더 나쁜 것은 생산에 게으른 개발 모듈을 유지하는 것입니다.

서식지는 각 환경 (해비타트)에서 특정 모듈을 활성화 또는 비활성화하는 설정을 제공합니다. 예를 들어 $ conf [ 'habitat'] = 'local'; settings.php 파일에서 (현재 사용하는 실제 변수는 현재 워크 플로우에 대해 구성 가능합니다). 비활성화 / 활성화 모듈은 hook_init에서 수행됩니다.

6-추천 자료 :

7-기능 사용에 대한 가능한 대안

Features 을 사용할 수 없거나 아직 (의용 할 수 없다면), 아래의 접근 방식 / 모듈이 어떤 유형의 대안을 제공하는지 확인할 수 있습니다.

수동 내보내기 / 가져 오기

이것들은 규칙 , 보기 등과 같은 모듈 (불완전한 목록!) 과 같은 모듈에 대해 관리자 UI를 통해 사용 가능한 일반적으로 알려진 기능 (단어 기능 을 피하기 위해 ... )입니다.

번들 사본

어떤 사람들은 번들 복사 모듈을 가능한 대안으로 생각합니다 . 다음에 대한 내보내기 / 가져 오기 지원이 있습니다.

  • 노드 유형.
  • 분류법.
  • 사용자.
  • 필드 API 필드.
  • 필드 그룹.

1
내가 본 최고의 답변.
No Sssweat

@NoSssweat Merci는 kudos를 위해 ...하지만 여전히 꽤 불완전한 것으로 간주한다는 것을 알고 있습니다. 예를 들어, 처리 기능의 "라이프 사이클"에 대한 내용은 거의 포함하지 않으며 영향 분석, 감사, 릴리스 관리, 권한 부여 및 (또 다른 주제 등)에 대해서는 아직 많이 언급하지 않았습니다.
Pierre.Vriens

1
@ Pierre.Vriens-감사합니다! 나는 당신의 훌륭한 답변과 어려운 결론에 도달했다고 생각합니다. 구성 요소 (views_views, dependency 등)별로 분할하는 방법을 시도했지만 기능을 생성하려고 할 때 충돌이 발생했습니다. 종속성을 확인하지 않고 충돌을 무시하지 않도록 기능을 구성해야 할 수도 있다는 것을 깨달았습니다.
stefgosselin

7

여러 개발자가 구성을 기능에 통합 할 때 병합 충돌이 발생할 수 있습니다. 기능 코드를 검토하기위한 몇 가지 지침을 작성했지만 가장 중요한 것은 다음과 같습니다.

의도 된 코드 변경 사항 만 커밋하십시오.

이것은 무엇을 의미 하는가? 이는 각 개발자 커밋하기 전에 코드를 검토 해야 함을 의미합니다 . 개발자가주의하지 않고 의도하지 않은 코드 변경을 방지하는 "마법"은 없습니다.

  • 로 코드 변경 사항을 검토하십시오 git diff.
  • 를 사용하여 빠른 diff 패치를 git diff > blah.patch만들고 의도 한 구성 변경 사항 만 포함하도록 패치를 수동으로 수정하십시오.
    • 정보 파일의 뷰 내보내기에서 "mtime", 주석과 같은 것은 커밋에 포함될 필요가 없습니다.
    • 시간이 지남에 따라 구성 코드 차이 블록을 검토하는 데 능숙했습니다. 뷰 또는 패널에서 불필요한 변경 사항을보다 쉽게 ​​발견 할 수 있으며, 빠른 10ddvim은 패치의 변경 사항을 제거합니다 (예 : 패치).
    • "아, 필드와 관련하여 아무 것도 바꾸지 않았기 때문에 커밋하지 않겠다"고 생각 featurename.features.field_base.inc합니다.
  • 지금까지 사용하지 마십시오 git commit -a. 이것은 끔찍한 관행으로 사용을 방해해야합니다. 항상 명시 적으로 추가하고 커밋하십시오!
  • 사용 git rebase에 대한 지역 자식 가지 기능이 최신인지 확인합니다.
  • git merge 전략은 실제로 병합을 수행 할 때 도움이 될 수 있습니다.
    • git merge -s recursive -X patience (git 1.7+ iirc 필요).

마지막으로 패치 검토 또는 풀 요청으로 트렁크 / 안정화에 병합하기 전에 개발자가 코드를 검토하도록 개발자에게 사회적 제한을 추가하는 것을 고려하십시오. 사람들은 사회적 제한에 대해 화를 내지 만 코드를 검토하지 않은 것에 대해 스스로 화를 내야합니다.


패치 파일을 생성하는 것보다 git add -p특정 청크 만 커밋하는 것이 좋습니다.
donquixote
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.