dev-> stage-> production에서 마이그레이션 (CMI) 구성을위한 제안 된 워크 플로우는 무엇입니까?

몇 달 전에 drupalcamp가 있었고 누군가가 새로운 구성 (CMI) 시스템으로 배포 관리에 대해 물었습니다. 이상적인 워크 플로우 중 하나는 구성을 버전 제어로 유지하고 팀 구성원간에 구성을 마이그레이션 할 수있는 것입니다.

룸에서 우리가 알아낼 수 있었던 최선은 (부분적으로 DrupalCon Portland의 프리젠 테이션을 기반으로) 다음과 같습니다.

• 활성 구성 디렉토리를 무시하도록 버전 제어에 지시하십시오.
• 모든 구성을 스테이징 디렉토리에 복사하고 버전 제어를 확약하십시오.

그리고 settings.php를 사용하여 두 환경 사이의 active / staging 디렉토리를 되 돌리십시오. 그러나 한 서버에서 다음 서버로 배포 워크 플로를 파악하는 것은 복잡하지만 실행 가능하지만 여러 로컬 환경 (예 : 여러 개발자)에서 개발자 (또는 서로간에)로 제안 된 워크 플로는 무엇입니까? 동일하거나 유사한 환경을 공유하고 있으므로 한 팀원의 컴퓨터에서 변경 사항이 어떻게 발생합니까?

CMI 관리자와 조금 이야기를 나눈 후, 최선의 접근 방식에 대한 논의는 끝나지 않았지만 다음은 현재 가장 의미있는 것입니다.

지금은 간결하게 유지하려고하면 질문을 기반으로 확장하려고 시도하고 참조 된 문제가 공식 답변으로 해결 될 때.

먼저, 사실 ...

• 이미 언급했듯이 활성 및 준비 디렉토리가 있습니다. Active는 Drupal에서 완전히 관리하므로 직접 변경 (다른 위치로 전환하여 직접 또는 간접)하는 것은 지원되지 않습니다.
• 스테이징은 Drupal이 가져올 구성을 찾고 다른 방법으로는 신경 쓰지 않습니다.
• 가져 오기 프로세스는 중요하며 구성 변경은 특정 방식으로 사이트에 영향을 줄 수 있으며 유효성을 검사해야합니다. 텍스트 필드의 필드 유형을 작동하지 않는 엔티티 참조로 변경할 수 없습니다.
• 구성 가져 오기는 항상 모든 구성에서 실행해야 하며 단일보기 또는 노드 유형을 가져올 수 없습니다. 시도되었지만 종속성에 대처하려고 시도하거나 제거하거나 이름을 바꾸는 등의 작업으로 인해 시스템이 매우 복잡해졌으며 작동하지 않았습니다.
• 기본 구성을 다시 설치하는 유일한 방법은 해당 모듈을 다시 설치하는 것입니다. 즉, 먼저 모든 구성 (예 : 필드) 을 제거 하려고합니다 . 따라서 이것은 실제로 옵션이 아닙니다. 업데이트 기능의 수동, 특정 변경은 가능하지만 너무 지루합니다.
• 기능 모듈에서 설명한대로, 지속적인 구성 배포가 아니라 재사용 가능한 기능을 제공하는 데 중점을 둘 것입니다. 이것이 처음에 설계된 것입니다.

따라서 스테이징 디렉토리를 버전 제어에 두는 것이 좋습니다. 그런 다음 각 개발자는 전체 활성 디렉토리를 복사하거나 특정 구성 파일을 사용하여 자신이 넣은 내용을 완전히 제어 할 수 있습니다. 그런 다음 스테이징 디렉토리 변경 사항이 커미트되어 프로덕션으로 푸시되고 구성 가져 오기가 실행됩니다 (UI 또는 drush).

지금까지 큰 대답. 모두 감사합니다!

우리는 최근 Drupal 8 프로젝트를 시작했으며 다음과 같은 워크 플로를 구현했습니다.

준비, 내보내기 및 세 개의 폴더가 활성화되어 있습니다. 개발자는 내보내기 위해 덤프합니다. 스테이징 상태로 유지하고 싶지 않습니다. 공유 구성이 준비 폴더에 직접 저장되지 않은 경우 작업하기가 더 쉽다고 생각합니다. 그것은 단지 벌목입니다. 나는 이것에 대한 어려운 사실이 없습니다 ...

현재 drupal 8 프로젝트 템플릿은 github에서 사용할 수 있습니다. 또한 devleoper worflow 속도를 높이기 위해 편리한 drush 명령을 작성했습니다. 활성에서 내보내기로 수동 복사가 필요하지 않습니다.

• 프로젝트 템플릿 : https://github.com/webflo/d8-project-template
• 추가 Drush 명령 : https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

나는 이것을 시도하지 않았지만, 나의 계획은 내가 관심있는 구성만을 포함하는 "기본"구성 파일을 포함하는 사용자 정의 모듈을 만드는 것입니다. 다른 모듈에는 다른 모듈을 무시하는 구성이 포함될 수 있다고 생각합니다. (그렇지 않으면 가능해야합니다).

config 폴더를 그대로 두어야한다고 생각합니다. 무시해. 설치시 모든 개별 모듈의 구성 파일에서 자동으로 생성됩니다. 길은 길고 무작위입니다. 이 모든 것을 저장소에 보관했다면 별도의 저장소가 필요하고 불필요한 기본 구성 파일 톤을 가지고 다닐 것입니다.

사용자 정의 모듈에 구성을 넣으면 기본 코드베이스의 일부가됩니다.

배포 프로세스는 다음과 같습니다.

1. 힘내거나 새 파일을 얻으려면 무엇이든하십시오.
2. 캐시를 비 웁니다.
3. 기본 구성을 재설정하십시오. (사용자 정의 모듈 파일에서)

원하는 경우 각 환경에 대해 고유 한 구성으로 사용자 정의 모듈을 작성할 수 있습니다.

참고 : 이 질문과 관련하여 가장 엄격한 의미의 답변은 아니지만 감사합니다. 어쨌든 여기에 넣고 기능이 8.x 릴리스이고 먼지가 있으면 다시 방문하고 편집 / 삭제합니다. 조금 더 정착했습니다. 이것은 의견에 비해 너무 컸으며 :-) 내 £ 0.02를 얻고 싶었습니다.

Features의 열렬한 팬으로서 Features 모듈의 D8 화신을 주시하는 것이 좋습니다 .

프로젝트 페이지에서 가져온

Drupal 8의 새로운 기능은 3.x 버전의 새로운 구성 관리 시스템과 통합 될 예정입니다. 단순 사이트 구성 만 내 보내야하는 경우 기능 대신 D8 구성 관리 시스템을 사용해야합니다. D8의 기능을 사용하여 번들 된 기능 (예 : "사진 갤러리 기능")을 내 보냅니다.

내가 방법 좀 볼이 생각 dev에 대한 더 쉽게 만드는 것입니다 팀 사이트의 작은 부분에서 작동합니다. 아직 알 수없는 변수가 너무 많아서 아직 워크 플로에 들어 가지 않겠지 만 현재 기능 배포 절차와 크게 다른 것을 볼 수는 없습니다.

CMI는 굉장합니다. 그러나 대부분의 사이트는 여전히 기능 모듈로 끝납니다 (모든 컨텐츠 유형, 권한 등을 내보낼 필요가 없기 때문에 적은 양이지만)