Środowiska kodowania dla deweloperów

W przypadku inżynierii platformy jednym z typowych wyzwań jest zapewnienie, że deweloperzy mogą szybko i spójnie konfigurować swoje środowiska kodowania, szczególnie gdy nowi deweloperzy dołączają do zespołów, deweloperzy przełączają się między projektami lub wymagają skalowania. Automatyzacja konfiguracji środowisk deweloperskich może usprawnić dołączanie i wyeliminować utratę czasu z powodu błędów konfiguracji lub uszkodzonych zależności. Dzięki zapewnieniu wstępnie skonfigurowanych środowisk lub skryptów konfiguracji zespoły mogą skupić się na programowaniu, a nie marnować czasu na rozwiązywanie problemów z niespójnościami środowiska.

Podejście do zarządzania środowiskami deweloperów może się różnić, ale często obejmuje wirtualizację, konteneryzację i standardowe szablony zgodne z potrzebami organizacji. Może to obejmować od w pełni zwirtualizowanych środowisk systemu Windows po kontenery hostowane w chmurze na potrzeby programowania w systemie Linux. Ponadto tworzenie szablonów "start right", które promują spójność, najlepsze rozwiązania i zabezpieczenia, ponieważ kod jest niezbędny do utrzymania dobrze zdefiniowanego, powtarzalnego procesu, który skaluje się między zespołami. Gwarantuje to, że przepływ pracy programowania jest uruchamiany nie tylko bezproblemowo, ale nadal jest zgodny z najlepszymi rozwiązaniami, utrzymując projekty na bieżąco i zgodne ze standardami zabezpieczeń i działania.

Automatyzowanie konfiguracji środowiska kodowania dla deweloperów

Tworzenie i normalizacja środowiska kodowania deweloperów może stanowić główne wyzwanie w systemach inżynieryjnych. Najważniejsze problemy obejmują:

• Długie czasy dołączania: Może upłynąć kilka tygodni, aby nowy deweloper współtworzył, zwłaszcza w przypadku przenoszenia deweloperów między projektami lub wprowadzenia wykonawców.
• Niespójności: Różnice między środowiskami deweloperskimi a systemami ciągłej integracji często prowadzą do problemów "działa na mojej maszynie".
• Niestabilność środowiska: Eksperymentowanie z lub uaktualnianie struktur i oprogramowania może spowodować przerwanie istniejących konfiguracji, co może spowodować potencjalnie długie i złożone rozwiązywanie problemów.
• Opóźnienia przeglądu kodu: zmiany konfiguracji potrzebne do przeglądów kodu mogą spowolnić programowanie, ponieważ trzeba je cofnąć później.
• Zwiększenie skali dla wszystkich uczestników projektu: role niezwiązane z programowaniem (takie jak operatorzy, sponsorzy biznesowi i sponsorzy biznesowi) również muszą być przeszkoleni i zaangażowani, co powoduje większe opóźnienia.

Aby rozwiązać te problemy, standaryzacja i automatyzacja konfiguracji środowisk deweloperskich za pomocą narzędzi, skryptów lub środowisk konteneryzowanych/zwirtualizowanych może pomóc. Wstępnie skonfigurowane środowiska dostosowane do określonych projektów lub potrzeb organizacji mogą zapewnić spójność, skrócić czas konfiguracji i zwiększyć ogólną produktywność.

Środowiska kodowania dla systemów Windows i Linux

W przypadku kierowania do systemu Windows na potrzeby zamiany stacji roboczej lub pełnej wirtualizacji maszyny wirtualne ogólnie zapewniają najlepszą funkcjonalność. Takie podejście jest korzystne w przypadku programowania klientów systemu Windows, zarządzania aplikacjami internetowymi w pełnym środowisku .NET lub obsługi usług systemu Windows. Maszyny wirtualne hostowane w chmurze, takie jak Microsoft Dev Box, oferują pełną wirtualizację stacji roboczej z systemem Windows z integracją z oprogramowaniem do zarządzania komputerami. Alternatywnie lokalne maszyny wirtualne mogą być używane z narzędziami, takimi jak HashiCorp Vagrant do zarządzania środowiskami, a program HashiCorp Packer może służyć do tworzenia obrazów maszyn wirtualnych zarówno dla rozwiązania Vagrant, jak i usługi Dev Box.

W przypadku kierowania do systemu Linux wirtualizacja obszarów roboczych jest lepszym rozwiązaniem, koncentrując się na środowiskach specyficznych dla projektu lub aplikacji zamiast zastępowania pełnego pulpitu. Kontenery hostowane w chmurze są typowym wyborem, z opcjami takimi jak GitHub Codespaces, które zapewniają oparte na chmurze środowisko kontenera deweloperskiego zgodne z programem VS Code, JetBrains IntelliJ i narzędziami opartymi na terminalach. Jeśli opcje chmury nie spełniają Twoich potrzeb, protokół SSH lub tunel zdalny programu VS Code obsługuje łączenie się z własnymi maszynami wirtualnymi z systemem Linux. Ponadto kontenery lokalne są opcją, jeśli wolisz uruchamiać kontenery deweloperskie lokalnie. Program VS Code i intelliJ zapewniają niezawodną obsługę tych środowisk. Aby uzyskać większą elastyczność, można również użyć maszyn wirtualnych hostowanych w chmurze, w których można sSH bezpośrednio do maszyn wirtualnych z systemem Linux samodzielnie zarządzanych. W przypadkach, gdy deweloperzy pracują wyłącznie w systemie Windows, Podsystem Windows dla systemu Linux (WSL) oferuje wygodne lokalne rozwiązanie deweloperskie systemu Linux. Dystrybucje WSL można eksportować i udostępniać między zespołami. Usługi oparte na chmurze, takie jak Microsoft Dev Box , obsługują również środowisko WSL na potrzeby tworzenia aplikacji dla systemu Linux.

Używanie szablonów aplikacji na potrzeby spójności i standaryzacji

Aby promować spójność, standaryzację i najlepsze rozwiązania w zespołach programistycznych, organizacje mogą używać szablonów aplikacji w ramach podejścia "wszystko jako kod". Te szablony mogą usprawnić programowanie, zapewniając zespołom utrzymanie się na ustalonych torach. W przypadku organizacji korzystających ze wzorca monorepo narzędzia takie jak interfejs wiersza polecenia dla deweloperów platformy Azure (azd) mogą służyć do tworzenia szablonów zawierających nie tylko konfiguracje źródła aplikacji, ale także konfiguracje środowiska i przepływy pracy ciągłej integracji/ciągłego wdrażania.

Podczas tworzenia szablonów na potrzeby programowania warto rozważyć różne kluczowe obszary, aby upewnić się, że szablony są kompleksowe i spójne, przestrzegając najlepszych rozwiązań:

• Przykładowy kod źródłowy: dołącz przykładowy kod źródłowy, aby kierować deweloperów do zalecanych języków, modeli aplikacji, usług, interfejsów API, zestawów SDK i wzorców architektury.
• Skrypty kompilacji i wdrażania: dołączanie skryptów, które oferują spójny sposób wyzwalania kompilacji i wdrażania lokalnie lub w środowisku piaskownicy. Upewnij się, że konfiguracje debugowania w środowisku IDE lub edytorze zostały dołączone do synchronizacji z potokami ciągłej integracji/ciągłego wdrażania.
• Konfiguracja ciągłej integracji/ciągłego wdrażania: udostępniaj przepływy pracy lub potoki do tworzenia i wdrażania aplikacji, co umożliwia korzystanie z przepływów pracy wielokrotnego użytku i scentralizowanych przepływów pracy. Traktuj je jako szablony "start right" i upewnij się, że umożliwiają ręczne wyzwalanie w razie potrzeby.
• Zasoby infrastruktury jako kodu (IaC): obejmują zalecane konfiguracje i odwołania do centralnie zarządzanych modułów w celu zapewnienia, że konfiguracje infrastruktury są zgodne z najlepszymi rozwiązaniami.
• Zabezpieczenia i zasady jako zasoby kodu: dodaj pliki konfiguracji związane z zabezpieczeniami, takie jak CODEOWNERS i dependabot.yaml, w celu włączenia zabezpieczeń bezpośrednio do procesu programowania. Zaplanowane przepływy pracy skanowania zabezpieczeń, w tym narzędzia, takie jak Microsoft Defender dla Chmury, powinny być udostępniane w celu osadzenia zabezpieczeń w potoku ciągłej integracji/ciągłego wdrażania i zwiększenia bezpieczeństwa łańcucha dostaw.
• Możliwość obserwowania, monitorowanie i rejestrowanie: podaj konfiguracje konfiguracji dla narzędzi do monitorowania, takich jak IaC na potrzeby wdrażania agenta lub konfiguracji jako kodu na potrzeby monitorowania pulpitów nawigacyjnych. Dołącz przykładowy kod do rejestrowania i śledzenia rozproszonego, aby zapewnić efektywne monitorowanie aplikacji po wdrożeniu.
• Konfiguracja środowiska kodowania: dodawanie plików konfiguracji dla linters, formaterów i środowisk IDE oraz konfigurowanie skryptów dla zwirtualizowanych środowisk deweloperskich, takich jak devcontainer.json, devbox.yaml lub pliki związane z platformą Docker.
• Konfiguracja testu: dostarcza pliki do testowania jednostkowego i bardziej rozbudowanych scenariuszy testowania przy użyciu narzędzi, takich jak testowanie playwright firmy Microsoft lub testowanie obciążenia platformy Azure.

Konfiguracja narzędzia do współpracy: jeśli jest obsługiwana, dołącz szablony zadań/problemów lub szablony żądań ściągnięcia jako kod. Opcjonalnie udostępniaj przepływy pracy, które używają dostępnych interfejsów API lub interfejsów API do aktualizowania systemów lub konfigurowania narzędzi do współpracy, takich jak Microsoft Teams lub Slack.