Kompozytor bez ciągłej integracji

Jeśli jesteś programistą WordPress, który korzysta z Composera bez ciągłej integracji, istnieje duże prawdopodobieństwo, że zostaniesz z kluczowym krokiem do ustalenia, jak zarządzać katalogiem dostawców podczas wdrażania wtyczek.

To znaczy:

• Wiemy, że poddawanie całego katalogu dostawców pod kontrolę źródła to zły pomysł,
• Inni programiści, którzy są zaznajomieni z korzystaniem z Composera, powinni być w stanie uruchomić się i uruchomić bez konieczności wielu instrukcji,
• Ciągła integracja nie jest stosowana z wielu powodów,
• Pozostaje nam konieczność dostarczenia elementu wynikowego klasy produkcyjnej, który korzysta z pewnych zależności, ale nie z innych.

O ile powyższe punkty mogą opisywać naszą sytuację, nie mówią nam, co możemy z nią zrobić.

Innymi słowy, oto przykład użycia: zbudowałeś dla kogoś wtyczkę WordPress. Ta wtyczka używa różnych zależności, z których wszystkie są utrzymywane przez Composer.

Nie sprawdzasz katalogu dostawcy w repozytorium, ale także nie używasz ciągłej integracji do wdrażania wtyczki. Zamiast tego klient lub osoba trzecia.

Więc co wtedy?

Dystrybucja z Composerem bez ciągłej integracji

Krótka wersja jest taka:

Wyeksportuj gałąź główną (lub gałąź wydania lub jakkolwiek ją nazwiesz) z lokalnej kopii wtyczki, a następnie upewnij się, że uruchamiasz polecenie Composer, które instruuje go, aby utworzyć katalog dostawcy bez zależności na poziomie rozwoju.

Następnie możesz spakować wygenerowane archiwum i rozesłać je do klienta.

Ale jak?

Po pierwsze, zakładam, że lokalna kopia twojej wtyczki nie ma kopii katalogu dostawcy, ale ma cały najnowszy kod pobrany ze zdalnego repozytorium.

Oznacza to, że masz najnowszą, stabilną wersję kodu gotową do wydania, ale nie jesteś jeszcze na to gotowy, ponieważ nie ma ona niezbędnych zależności do, powiedzmy, automatycznego ładowania i innych podobnych funkcji.

Pierwszym krokiem będzie wyeksportowanie lokalnego repozytorium do archiwum. Oto, jak możesz to zrobić, upuszczając go na pulpit:

$ git archive -o ~/Desktop/plugin-name.zip HEAD

Następnie poinstruuj Composer, aby zainstalował zależności, które są poza dyrektywą require-devcomposer.json w twoim pliku:

$ composer install --no-dev

Teraz możesz zarchiwizować wygenerowany katalog we wtyczce i rozpowszechniać ten plik.

Czy to jest idealne?

Nie powiedziałbym, że to jest idealne, ale jest to rozwiązanie przypadku użycia, który z pewnością istnieje, więc powiedziałbym, że jest to coś, co można zrobić, aby rozwiązać konkretny problem.

Ostatecznie, jeśli szukasz sposobu na dystrybucję wtyczki WordPress korzystającej z Composera bez ciągłej integracji, jest to sposób na zrobienie tego.

Zdaję sobie jednak sprawę, że jest to konkretny przypadek użycia i dlatego ma określone rozwiązanie.