최고의 배포 전략은 무엇입니까?

82

Magento 저장소를 설정하려면 자체 설치 가능한 확장 프로그램을 개발해야 할뿐만 아니라 최종 편집 속성, 범주, 제품, 가격 규칙 CMS 페이지 등의 "수동 입력"작업이 필요합니다. 시스템 구성 변경.

개발에서 스테이징 및 프로덕션 환경에 이르기까지 Magento 저장소를 배포 할 때 최상의 전략을 간략히 설명해 주실 수 있도록 도와 드리겠습니다.

내 전략 중 하나는 위에서 언급 한 개체를 프로그래밍 방식으로 만드는 "배포 모듈"을 작성하는 전략이지만 시간이 많이 걸리는 작업이며 때로는 약간 과잉 인 것처럼 보입니다.

최근 Selenium IDE를 사용하여 관리 작업을 재현하기 시작했지만 모든 테스트 스위트를 설정하는 데 필요한 시간이 위에서 언급 한 시간과 멀지 않았습니다.

최적의 솔루션은 Magento 시스템의 스냅 샷을 수행 할 수있는 모듈을 사용하여 배포 할 항목을 선택할 수 있습니다.

그래서:

배포 전략은 무엇입니까?
배치 할 항목을 선택할 수있는 Magento 시스템의 스냅 샷을 수행 할 수있는 모듈이 있습니까?
그러한 모듈이 존재하지 않고 그러한 모듈이 합리적인 솔루션이라면 모듈 개발에 관심이있는 사람이 있습니까?

감사합니다!

deploy admin entities

— 알레산드로 론치
소스

다른 태그 나 태그 범주가 필요할 수 있습니다. 일회성 상점이거나 서비스 제공 업체로서 일반적인 제안을 찾고 있습니까? 후자의 경우 "엔터티 데이터에 대해 클라이언트가 얼마나 많은 제어를 원하는지에 따라 달라집니다"라는 답이 나오게됩니다.

— benmarks

내 관점은 개발자 팀에 속한 개발자 중 하나입니다. 범주 구조와 같이 작동하기 위해 데이터가 필요한 섹션을 개발한다고 가정 해보십시오. 관리자를 통해 구조를 만들고 코드를 작성하고 코드를 푸시합니다. 최선의 전략이 필요한 카테고리 구조를 만드는 코드를 작성하고 푸시하는 것인지 궁금합니다. 내 카테고리 구조 또는 설정이 자신을 푸시 한 다른 개발자의 카테고리 구조 또는 설정과 충돌하는 경우 충돌을 어떻게 처리합니까? 그게 내 요점이야

— Alessandro Ronchi

@AlessandroRonchi 이것은 논쟁의 여지가 있으며 결코 일어날 수없는 갈등입니다. 귀하의 카테고리 구조는 대대적으로 변경되어야하는 것이 아니기 때문에 한 개발자가 다른 개발자가 알지 못하는 한 귀하의 구조를 크게 변경해서는 안됩니다. 이런 일이 발생하면 개발자 간 통신을 해결해야합니다. 일반적으로 사이트의 카테고리 구조는 첫날부터 고정되어야하며 다시 변경할 필요가 없습니다. 추가하기 만하면됩니다. 변경해야 할 경우 처음에는 올바르게 범위를 지정하지 않았습니다.

— ProxiBlue

불행히도 @dedmeet는 내가 알고 일하는 세상에서 매일 상황이 바뀐다. 고객이 마음을 바꾸고 개발자가 마음을 바꾸면 검은 백조가 발생합니다. 나는 변화에 대비해야한다. 어쨌든 카테고리 구조를 첫날부터 변경할 필요가 없더라도 전체 부분의 작은 부분 일 뿐이며 전체 부분은 작업을 수행하기 위해 변경되어야하는 "진행중인 작업"프로젝트입니다.

— Alessandro Ronchi

물론, 우리는 끊임없이 변화하는 환경에서 일하고 있지만, 여전히 카테고리 구조 충돌이 일어나지 않아야한다고 주장합니다. 각각 구조가 바뀔 때 여러 가지 지점이 존재해서는 안되며, 이는 문제를 일으키고 시간 낭비를 초래할 것입니다. 개발자 b가 구조를 변경하는 데 시간을 소비하는 이유는 무엇입니까? 개발자 b는 동일한 구조를 다른 구조로 변경하고 둘 다 작업을 추진합니까? 구조가 변경되어야하는 경우, 프로젝트와 관련된 모든 개발자는 새로운 구조를 다루는 과정에 참여해야합니다. 이러한 상황이 언제 발생할 수 있는지 이해하는 데 도움이되는 예를 들어 주시겠습니까?

— ProxiBlue

39

내 의견은 모든 것을 스크립트하는 것입니다. 일반적으로 특정 모듈과 기능적으로 직접 관련되지 않은 모든 것에 대한 기본 구성 모듈이 있습니다. (예 : 사용자 정의 URL을 작성하면 이전 사이트 URL을 새 사이트 URL로 다시 작성) 모듈과 관련된 모든 것을 자체 설치 스크립트에 추가합니다.

이것에 대한 사고 방식은 새로운 db를 사용하여 사이트를 다시 설치 해야하는 경우 모든 것이 원래대로 돌아온다는 것입니다. 이것은 또한 라이브 DB의 복사본으로 uat 사이트를 주기적으로 업데이트한다는 사실에 도움이됩니다. 그런 다음 uat의 모듈은 구성에 다시 슬롯으로 들어가면서 계속 작동합니다.

우편 요금, 장바구니 규칙 등 (기본적으로 고객이 관리자로 관리하는 것들)에 대한 변경은 '휘발성 데이터'로 간주되며 스크립팅되지 않습니다. 여기에는 제품 데이터가 포함됩니다. 고객은 옵션이 있으며 먼저 uat 사이트에서 새로운 수입품을 테스트하도록 권장됩니다.

고객에게 속성을 작성하지 말고 티켓 요청을 통해 작성하도록 요청하십시오. 그러면 속성에 대한 고객의 의도가 무엇인지에 대한 정보를 수집 할 수 있으며 때로는 더 나은 제안이 있거나 속성이 무엇인지, 선택 가능한 속성을 처리 할 때 더 나은 코드를 만들 수 있습니다. 깨끗한.

예 스크립팅은 시간이 오래 걸리지 만 나중에 전체 사이트 구성 설정을 수동으로 다시 만드는 데 시간이 오래 걸립니다. 무언가를 잊어 버려 사이트가 제대로 작동하지 않거나 중요한 구성 설정이 누락 된 로컬 사이트에서 새로운 개발 작업을하는 경우에도 당황 스러울 수 있습니다.

— 프록시 블루
소스

1

나는 dedmeet에 동의합니다. 모든 업데이트를 스크립팅하는 방법을 처음 배우면 초기 작업이 더 어려울 수 있지만 3-4 명의 개발자를위한 구성 업데이트를 수동으로 적용해야하는 경우 준비, uat 및 live, 조정 및 실제 작업에 훨씬 더 많은 시간이 소요됩니다. 우리의 작업 흐름은 매우 유사합니다. (재사용 가능한) 확장에 구성이 필요한 경우 여기에 배치하십시오. 구성이 클라이언트 특정인 경우 프로젝트 별 확장에 넣으십시오. 몇 가지 예외 중 하나는 전혀 업데이트 / 생성하기 어려운 장바구니 규칙입니다.

— Matthias Zeis

1

필자는 필요한 구성 스크립트를 작성하는 데 도움이되는 모듈을 릴리스하여 설치 스크립트를 수동으로 작성해야하는 일상적인 작업을 제거했습니다. 모듈은 core_config_data 테이블의 그리드 표시를 사용하여 내보낼 구성 값을 선택할 수 있습니다. 내 인생을 조금 더 단순하게 만들고, 다른 사람들에게도 도움이 되길 바랍니다. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

몇 달 전에 몇 가지 연구를 했었습니다. 참조 할 수있는 사이트는 다음과 같습니다.

~~Magento 기본 URL 및 개발 / 스테이징 설치~~
Magento 개발 및 배포
Magento Git 안내서 및 작업 흐름
분기를 위해 Magento MySQL 데이터베이스 덤프

— 오 우즈 셀리 크데 미르
소스

1

감사합니다, 나는 그들 모두를 읽고 몇 가지 고려 사항을 가지고 다시 올 것입니다.

— Alessandro Ronchi

나는 모두 줄 자원을 읽었다; 나는 그들 중 일부를 이미 알고 있었고, 내가 모르는 다른 사람들은 매우 흥미 롭습니다. 어쨌든 그들 중 어느 것도 내 문제에 대한 해결책이 아니며 내 요구를 충족시키기 위해 확장 프로그램을 스케치하기로 결정했습니다. 소중한 조언을 해주신 모든 분들께 감사드립니다. 나는 몇 가지 결과를 가지고 여기로 돌아 오기를 바랍니다.

— Alessandro Ronchi

Alessandro에게, 나는 더 편안한 기술을 찾고있는 당신의 길을보고 싶습니다!

— Oğuz Çelikdemir

18

귀하의 고려 사항이 다른 환경을 동기화하여 유지하는 문제를 해결하려는 의도로 "Mageploy"라는 확장 기능을 개발하도록 영감을 주었기 때문에 모든 분들께 감사드립니다.

http://www.mageploy.com

Mageploy는 이미 몇 가지 이점이있는 몇 가지 프로젝트에서 이미 사용하고 있어도 확장, 문서화 및 완벽하게 테스트되어야합니다.

오픈 소스이며 도움이나 제안이 있으면 감사하겠습니다.

문안 인사

— 알레산드로 론치
소스

7

스크립트를 설치하고 엔티티를 작성하는 것과 관련하여 필자의 일반적인 생각은 모듈에 필요하거나 예상되는 경우 설치 스크립트의 일부로 작성해야한다는 것입니다.

최근에는 개발 / 단계 / 제작 측면에서 클라이언트가 공동 작업 할 수 있다는 의미이므로 준비 사이트를 콘텐츠의 마스터 복사본으로 준비 사이트를 사용합니다. 과거에 우리가 겪었던 가장 큰 문제는 특히 제품 업로드와 관련하여 클라이언트와 컨텐츠 항목을 조정하는 것입니다.

스냅 샷이 어떻게 작동 할 것이라고 생각 했습니까? 이상적인 세계에서는 특정 유형 (제품, 카테고리, CMS 등)에 대한 두 데이터베이스 간의 차이점을 보여주고 변경 사항을 서로 병합 할 수있는 도구가 있지만 사용 가능한 것을 알지 못합니다. 그.

— 폴
소스

1

"스크립트를 설치하고 엔티티를 작성하는 것과 관련하여 모듈에 필요하거나 예상되는 경우 설치 스크립트의 일부로 작성해야한다는 느낌이 들었습니다." 이것은 가장 중요한 사항이며 구성 설정에 적용됩니다. 빠른 테스트 : repo를 복제하고 환경을 설치하기 위해 새로운 개발자가 필요할 때 시스템이 작동하려면 무엇이 필요합니까?

— benmarks

구성에 대해 공동 작업하기 위해 준비 사이트를 클라이언트와 공유하는 것은 이론상 훌륭합니다. 실제로, 고객은 99 %의 시간을 변경 한 모든 내용을 알려주지 않으므로 문제를 쉽게 해결할 수 있습니다. 우리는 고객이 장바구니 규칙, 카테고리, 제품 또는 이와 유사한 방식으로 물건을 처리하도록 허용 할 수 있지만 구성을 방해하지는 않습니다.

— Matthias Zeis

6

내 의견으로는 속성, 카테고리, 제품, 가격 규칙은 "배치 전략"과 관련이 없으며 이러한 모든 항목은 상점마다 고유하며 대부분의 경우 제품에 대한 적절한 분석 및 연구가 필요합니다 팔려고합니다.

언급 한 모든 요소의 유사한 구성으로 "한 크기에 맞는"상점을 작성하는 경우 모든 상점에 필요한 모든 설정을 완료 한 후에 데이터베이스를 "스냅 샷"내보내기로 만들 수 있습니다.

— 러거
소스

아니, "하나의 크기가 모두 맞습니다"는 요점이 아닙니다. 개발자가 소스 코드를 개발자 팀의 다른 멤버 중 하나와 병합 할 때가되었을 때와 같은 상황입니다.이 경우에는 마법을 수행하는 소스 제어 시스템이 있습니다. 내 질문은 구성 설정과 일반적인 관리자 설정 및 항목과 같은 "비 개발"항목을 병합 할 수있는 기회와 관련이 있습니다.

— Alessandro Ronchi

확인 아, 즉 더 명확하게

— 룻거

우리가 완전히 새로운 웹 사이트를 만들고 있다고하자, 오래된 데이터와 관련된 문제는 거의 없습니다. 우리의 모든 개발자들은 거의 항상 같은 데이터베이스를 개발에 사용합니다. 그것은 많은 문제를 해결합니다. 다른 경우에는 어떤 종류의 로드맵 / 스크립트에 필요한 모든 단계를 작성하고 병합 후 다시 적용하는 것보다 더 나은 해결책은 없습니다. "magento core"관리자 설정을 한 사람 만 담당하는 경우 여러 단계를 거치지 않아야합니다. 나는 이것을 한 번 발견했지만, 그것을 시도한 적이 없다 tinybrick.com/magento-modules/admin-tools/…

— Rutger

2

두 가지 뛰어난 시간 절약 도구를 추가하고 싶습니다.

개발 용 : Magicento 플러그인이 포함 된 PhpStorm IDE
배포 : Magento를위한 Capistrano 레시피 Magentify

— 곤돌라
소스

Magentify에 대해 알려 주셔서 감사합니다. 몰랐으며 시도해 보겠습니다. 그러나 필자는 코드 기반을 게시한다는 의미에서 배포하는 것보다 다른 개발 환경을 동기화하는 데 더 중점을 두었습니다. Mageploy는 Magentify와 통합 될 수 있지만 서로 다른 환경에서 서로 다른 특정 ID에 관계없이 데이터베이스 변경 내용의 일부를 자동으로 유지하는 데 사용되는 다른 도구입니다. 감사합니다. Alessandro

— Alessandro Ronchi