https://thedotnetblog.com/pl/tags/vsix/Articles, tutorials and insights from the .NET community.Hugopl@thedotnetblog (The .NET Blog)@thedotnetblogThu, 23 Jul 2026 00:00:00 +0000https://thedotnetblog.com/pl/news/emiliano-montesdeoca/visual-studio-extension-ci-with-github-actions/Thu, 23 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pl/news/emiliano-montesdeoca/visual-studio-extension-ci-with-github-actions/Powtarzalny przepływ GitHub Actions dla wersjonowania i publikacji VSIX jest teraz wystarczająco prosty, że ręczne kroki wydania są trudne do uzasadnienia.<p>Oryginalne źródło: <a href="https://devblogs.microsoft.com/visualstudio/automating-your-visual-studio-extension-builds-with-github-actions/">Automating your Visual Studio extension builds with GitHub Actions</a></p> <p>Jeśli utrzymujesz rozszerzenia Visual Studio i wciąż wykonujesz znaczące części wydania ręcznie, to jest twój sygnał do modernizacji.</p> <p>Przepływ pracy pokazany w tym wpisie jest celowo praktyczny: stempluj wersję, buduj, publikuj artefakty testowe do galerii, a następnie publikuj stabilne bity do Marketplace. Bez ciężkiej ceremonii platformowej, tylko deterministyczne zachowanie wydania.</p> <p>To, co lubię najbardziej, to to, że wersjonowanie jest traktowane jako stan pipeline&rsquo;u, a nie element listy kontrolnej przed wydaniem. Ta jedna decyzja eliminuje zaskakującą liczbę błędów: niedopasowane metadane, nieaktualne wersje assembly i niespójne notatki wydania.</p> <p>Podział między publikacją do galerii a publikacją do Marketplace jest również operacyjnie dojrzały. Zespoły potrzebują miejsca na szybkie kompilacje walidacyjne, które nie niosą semantyki oficjalnego wydania. Wypychanie wszystkiego bezpośrednio do Marketplace jest wysokotarciowe i zachęca do ryzykownych skrótów.</p> <h3 id="silny-wzorzec-wydania-dla-zespołów-rozszerzeń">Silny wzorzec wydania dla zespołów rozszerzeń</h3> <ul> <li><strong>Na pull requesty i commity do main</strong>, produkuj artefakty CI VSIX i publikuj do galerii dla testerów.</li> <li><strong>Na oznaczone wydania (tagi)</strong>, publikuj podpisane i zweryfikowane pakiety do Marketplace.</li> <li><strong>Utrzymuj obsługę tokenów minimalną</strong> z dedykowanymi sekretami i zakresami o najmniejszych uprawnieniach.</li> </ul> <p>Moje stanowcze zdanie: <strong>ekosystemy rozszerzeń pozostają w tyle za ekosystemami aplikacji w dyscyplinie CI</strong>, ponieważ małe zespoły zakładają, że ręczne przepływy są do zarządzania. Są do zarządzania, dopóki nie przestaną być. Jedna pospieszna łatka, jeden zepsuty pakiet, jedna zapomniana aktualizacja manifestu i zaufanie spada.</p> <p>Te wielokrotnego użytku akcje są użyteczne, ponieważ kodują powtarzalną logikę wydania raz i pozwalają zespołom skupić się na jakości rozszerzenia zamiast na mechanice pakowania.</p> <p>Wciąż wymagany jest osąd inżynieryjny. Powinieneś bramkować publikację do Marketplace za kontrolami jakości i traktować manifesty publikacji jako audytowane artefakty wydania. Ale podstawowa złożoność pipeline&rsquo;u jest teraz wystarczająco niska, że ręczne wydania to w większości dług techniczny.</p> <p>Jeśli prowadzisz rozwój rozszerzeń, <strong>ustandaryzuj to teraz we wszystkich repozytoriach</strong>. Zyskasz lepszą identyfikowalność, łatwiejsze wdrożenie i mniej wąskich gardeł zależnych od jednej osoby.</p> <h3 id="sugerowane-wdrożenie">Sugerowane wdrożenie</h3> <ul> <li><strong>Zacznij od budowania plus publikacji do galerii</strong> dla jednego rozszerzenia.</li> <li><strong>Wprowadź stemplowanie wersji</strong> po zweryfikowaniu konwencji manifest-źródło.</li> <li><strong>Dodaj publikację do Marketplace</strong> dopiero po wdrożeniu zarządzania sekretami i bram wydania.</li> </ul> <p>Nie chodzi o gonienie za modą DevOps. Chodzi o niezawodność dla ludzi, którzy instalują twoje narzędzia i oczekują, że aktualizacje będą działać.</p> <p>Stabilne ekosystemy rozszerzeń buduje się tak samo jak stabilne aplikacje: z nudną, powtarzalną automatyzacją, która usuwa ludzkie zgadywanie.</p>