Open-source notACMS — pełna lista kontrolna
open-source,php,symfony,statyczna-stronaCzęść 5 z 5
To część 5 serii o przygotowaniu notACMS do wydania jako open-source. Część 4 opisuje wzorzec lokalnych nadpisań. Oryginalna seria o migracji z WordPressa opisuje samą migrację.
Spędziłem miesiąc przygotowując kod mojej osobistej strony do wydania jako open-source. Nie dlatego że spodziewałem się tysięcy kontrybutorów — ale dlatego że publiczne udostępnienie zmusiło mnie do napisania dokumentacji, dodania testów, naprawy luk bezpieczeństwa i uczynienia architektury faktycznie wielokrotnego użytku. Kod który jest wystarczająco dobry żeby pokazać nieznajomym, jest lepszym kodem niż ten który nie jest.
Oto pełna lista kontrolna.
Dlaczego open-source projektu osobistego?
Odpowiedzialność — kod który pokażesz światu jest lepszym kodem. Dyscyplina dokumentacji — piszesz dokumentację gdy nieznajomi mogą ją czytać. I ostateczne ćwiczenie refaktoryzacji: czy byłbyś dumny pokazując ten kod?
notACMS to oparty na Symfony generator statycznych stron bez bazy danych, bez CMS i bez PHP zaangażowanego w serwowanie treści, na licencji Apache 2.0. Jeśli ktoś inny może go użyć, to waliduje architekturę.
Audyt: wynik 9.5/10 gotowości
| Kategoria | Wynik | Status |
|---|---|---|
| LICENSE (Apache 2.0) | 10/10 | ✅ |
| README | 10/10 | ✅ |
| Dokumentacja (5 docs, 1227 linii) | 10/10 | ✅ |
| Konfiguracja Rector | 10/10 | ✅ |
| Narzędzia jakości kodu (CS Fixer, PHPStan, Rector, Twig lint) | 10/10 | ✅ |
| Wytyczne kontrybucji | 10/10 | ✅ |
| Polityka bezpieczeństwa | 10/10 | ✅ |
| Workflows CI/CD | 10/10 | ✅ |
| Szablony Issue/PR | 10/10 | ✅ |
| Suite testów (368 testów, ~80% pokrycia) | 8/10 | ✅ |
| Zahardcodowane sekrety (udokumentowane w .env) | 10/10 | ✅ |
| CHANGELOG | 10/10 | ✅ |
| Ogółem | 9.5/10 | Gotowy |
Czego brakowało (i jak to naprawiłem)
GitHub Actions CI/CD — .github/workflows/ci.yml: PHP 8.5, composer install, validate, audit, Twig lint, Rector dry-run, CS Fixer, PHPStan, PHPUnit. Nic nie trafia na produkcję dopóki wszystkie checki nie przejdą.
CONTRIBUTING.md — Setup DDEV, standardy stylu kodu, proces PR, konwencje commitów. Bariera kontrybucji powinna być jedna komenda: ddev start.
SECURITY.md — Obsługiwane wersje, raportowanie luk (prywatne zgłoszenie), polityka aktualizacji bezpieczeństwa. Nawet dla jednoosobowego projektu, posiadanie zdefiniowanego procesu ma znaczenie.
CHANGELOG.md — Format Keep a Changelog 1.1.0, wpis początkowego wydania. Przyszłe wydania będą śledzić co się zmieniło.
Szablony Issue/PR — Raport błędu, propozycja funkcji, wytyczne PR. Dobre szablony redukują obciążenie poznawcze zarówno dla zgłaszającego jak i opiekuna.
CODEOWNERS — Śledzenie własności kodu. Jedna osoba, ale to dobra praktyka i sygnalizuje że projekt jest utrzymywany.
Suite testów — 368 testów z Unit i Integration, opisane w części 1 tej serii.
Rector jako zautomatyzowana refaktoryzacja
Rector używa withPreparedSets(codeQuality: true, codingStyle: true, deadCode: true, typeDeclarations: true, symfonyCodeQuality: true) plus withPhpSets(php85: true). Dry-run w CI, --fix w ddev code-fix. Co łapie: zbędne checki null, uproszczenia tablic, nowoczesna składnia PHP 8.5, martwy kod, deklaracje typów. Co pomija: ControllerMethodInjectionToConstructorRector — ErrorController potrzebuje wartości runtime których nie da się wstrzyknąć przez konstruktor.
Co pominąłem (i dlaczego)
Code of Conduct — Jednoosobowy projekt. Brak społeczności do zarządzania. Jeśli się zmieni, to się zmieni.
Informacje o licencjach stron trzecich — Zależności MIT nie wymagają atrybucji w źródle. Może później jeśli projekt urośnie.
100% pokrycia testami — Pozostałe ~20% to wysyłanie emaili, ścieżki kopiowania mediów, __invoke error controllera. Wysoki koszt uruchomienia, niski zwrot. 80% pokrywa wszystkie publiczne API, główne ścieżki kodu i przypadki brzegowe.
Pipeline deployowania
ddev code-check # Composer validate + audit, Twig lint, Rector, CS Fixer, PHPStan
ddev test # 368 testów, 490 asercji
./deploy.sh --prod
Brama jakości: nic nie trafia na produkcję dopóki wszystkie checki nie przejdą. Skrypt deployu działa wewnątrz produkcyjnego kontenera PHP gdzie znana jest poprawna architektura CPU. Po buildzie nginx już serwuje nowe statyczne pliki.
Wynik: notACMS
Generator statycznych stron oparty na Symfony, na licencji Apache 2.0, z dokumentacją, testami, CI i wzorcem lokalnych nadpisań. Nie framework — szablon projektu który możesz sklonować, customizować przez local/ i deployować. Cały kod, treść i konfiguracja mieści się w jednym repozytorium gita. Backup to git push.
Ta seria zaczęła się od 368 testów, przeszła przez audyt AI, poprawki bezpieczeństwa i wzorzec lokalnych nadpisań. Po wydaniu, kolejne posty opisują pipeline budowania, budowę produkcyjnego motywu i wyszukiwarkę Pagefind. Oryginalna seria o migracji z WordPressa opowiada historię jak ten kod powstał.