Udostępnij ten wpis
Wstęp
Temat na pierwszy materiał na tym blogu nie jest przypadkowy. Myśląc o kolejnych artykułach, które chciałbym publikować na tym blogu, mam wrażenie, że umiejętność tworzenia środowisk testowych BC jest absolutnie kluczowa i szczególnie przydatna. Chodzi tu o tworzenie własnych środowisk testowych, na których każdy z Was mógłby samodzielnie i swobodnie przetestować konkretne funkcje, które będę omawiał na blogu.
Co tu znajdziesz, a czego nie…
W tym artykule omówię środowiska testowe możliwe do utworzenia całkowicie poza tenantami produkcyjnymi klienta lub ewentualnie, gdy klient nie ma jeszcze tenanta produkcyjnego (takie też omówię). W tym artykule NIE omówię natomiast tzw. sandboxów czy baz testowych, które powstawać mogą na środowisku produkcyjnym już w trakcie wdrażania BC u klienta końcowego. O tym kiedy indziej :).
Po przeczytaniu…
Po przeczytaniu tego artykułu, jako konsultant lub programista będziesz potrafił/potrafiła dobrać typ środowiska testowego na każdą okazję i będziesz wiedział/wiedziała jak je tworzyć. Natomiast jako klient będziesz wiedział/wiedziała jakie typy środowisk testowych istnieją, jakie są możliwości każdego z nich oraz czy jesteś w stanie utworzyć środowisko testowe samodzielnie na własne potrzeby sprawdzenia nowej wersji BC lub funkcjonalności w tzw. standardzie.
Rodzaje środowisk testowych
Sposobów na utworzenie środowiska testowego BC jest co najmniej kilka bo jest też kilka rodzajów środowisk testowych możliwych do utworzenia. W tym artykule omówię najpopularniejsze z nich. Rodzaje (typy) środowisk testowych znacząco różnią się między sobą, dlatego warto poznać te różnice, aby jak najlepiej dobrać typ środowiska do potrzeb i oczekiwań.
| Typ środowiska testowego | Typ instalacji BC | Lokalizacja instalacji | Okres funkcjonowania |
|---|---|---|---|
| ¶ Wersja próbna BC | online | Środowisko BC na Azure w istniejącym lub nowym tenancie klienta | Bez limitu z danymi firmy Cronus LUB 30 dni z własnymi danymi firmowymi |
| ¶ Środowisko demonstracyjne na CDX | online | Pełne środowisko demonstracyjne Microsoft na Azure w fikcyjnym tenancie | 90 dni lub 1 rok z danymi firmy Cronus LUB 30 dni z własnymi danymi firmowymi |
| ¶ Kontener Docker | sandbox (online), on-premises | Na komputerze lokalnym | Bez limitu z licencją demonstracyjną i danymi firmy Cronus lub licencją Partnera |
| ¶ Instalacja z obrazu DVD | on-premises | Na komputerze lokalnym | Bez limitu z licencją demonstracyjną i danymi firmy Cronus lub licencją Partnera |
Wersja próbna BC
Rejestracja wersji próbnej
Aby utworzyć środowisko testowe poprzez skorzystanie z opcji wersji próbnej, należy wypełnić formularz rejestracyjny na stronie dostępny pod adresem: aka.ms/BCTrial ↗ bądź z poziomu strony domowej Business Central ↗, kliknąć w głównym banerze na przycisk Wypróbuj bezpłatnie (stan na dzień publikacji artykułu).
Wymogi dla adresu e-mail
Aby skorzystać z opcji wersji próbnej BC, w formularzu rejestracyjnym należy podać adres e-mail administratora. I tutaj uwaga – musi to być służbowy/firmowy adres e-mail. Nie można wskazać adresu dostarczonego przez konsumenckie serwisy mailingowe czy telekomunikacyjne tj. outlook.com, gmail.com, icloud.com, czy polskie wp.pl, onet.pl, interia.pl, itp.
Skąd taki wymóg? Otóż podczas tworzenia środowiska BC dla wersji próbnej, utworzone ono zostanie w istniejącym tenancie Microsoft 365 przypisanym do domeny, w której istnieje podany adres e-mail administratora. Jeżeli tenant dla domeny jeszcze nie istnieje, zostanie on automatycznie utworzony w trakcie tworzenia środowiska testowego BC pod wersję próbną.
Dla kogo
Jak więc widać, wersja próbna BC jest to opcja, która powinna być wykorzystywana, gdy jako Partner chcemy utworzyć środowisko testowe pod konkretnego klienta (np. dla którego prowadzimy w danym momencie działania pre-sales lub rozpoczynamy działania wdrożeniowe) podając adres e-mail w jego domenie, lub jako klient chcemy utworzyć środowisko testowe samodzielnie dla własnej firmy, aby sprawdzić BC. Po testach, środowisko tego typu może zostać przekształcone przy udziale Partnera w docelowe środowisko produkcyjne klienta lub może zostać anulowane… bądź samo wygaśnie.
Długość życia i warunki użytkowania
Wersję próbną możemy utworzyć tylko 1 raz dla danego tenanta. Jeżeli BC w wersji próbnej nie będzie używany przez 45 dni z rzędu, wersja próbna wygaśnie, a tenant BC zostanie automatycznie usunięty. Jeżeli przed wygaśnięciem wersji próbnej klient zdecyduje się przekształcić wersję próbną do wersji płatnej, limit 45 dni już nie będzie obowiązywał.
Jeżeli w trakcie korzystania z wersji próbnej, będziemy poruszali się po systemie jedynie w kontekście demonstracyjnej firmy Cronus i z jej ograniczeniami (oraz będziemy logowali się przynajmniej raz na 45 dni), środowisko testowe pozostanie aktywne tak długo ile będzie użytkowane. Jeżeli natomiast skonfigurujemy własną firmę, 30-dniowy okres próbny rozpocznie się z chwilą jej utworzenia w BC.
Możliwość przedłużenia okresu próbnego
Microsoft jest świadom, że 30 dni może być niekiedy zbyt krótkim okresem czasu, w którym klient powinien podjąć decyzję o wyborze systemu. Dlatego istnieje możliwość przedłużenia okresu próbnego o kolejne 30 dni, samodzielnie przez klienta. Tuż przed zbliżającym się upływem podstawowego okresu, wyświetlany jest komunikat użytkownikom tuż po zalogowaniu do BC zawierający link do poradnika do Przedłużenia okresu próbnego. Klikając w link uruchamiane jest kolejne 30 dni okresu próbnego. Przedłużenie samodzielne przez klienta jest jednorazowe.
Istnieje jeszcze możliwość drugiego przedłużenia okresu próbnego na kolejne 30 dni, ale jest to możliwe do wykonania tylko przez Partnera, do którego klient powinien się zwrócić z taką prośbą i również jest to jednorazowe.
Ograniczenia regionalne
To nie koniec wymogów i ograniczeń. Na nasze nieszczęście środowisko testowe BC pod wersję próbną da się utworzyć tylko na wybranych rynkach. Niestety nie ma wśród nich rynku polskiego, o czym zostaniemy powiadomieni zaraz po wprowadzeniu adresu e-mail lub później podczas wyboru Kraju lub regionu swojego konta oraz organizacji (brak Polski na liście wyboru). O utworzenie wersji próbnej BC dla klienta polskiego, polski Partner musi wnioskować bezpośrednio u dystrybutora CSP.
Obejście ograniczeń regionalnych
Gdy jako polski Partner chcesz utworzyć wersję próbną klientowi z kraju lub regionu, gdzie rejestracja wersji próbnej BC jest dostępna, powinieneś wybrać Kraj lub region zgodny z organizacją klienta – tj. w jakim kraju/regionie klient ma zarejestrowany tenant. Jeżeli i to nie pomoże, możesz zastosować obejście polegające na zmianie w ustawieniach swojej przeglądarki internetowej preferowanego języka wyświetlania stron internetowych. Gdy zmienisz preferowany język np. na region en-US, formularz umożliwi Ci utworzenie środowiska próbnego BC.
Wydajność sandboxów
Środowiska sandboxowe, a BC w wersji próbnej takim właśnie jest, oferują mniejszą wydajność niż środowiska produkcyjne BC. Dzieje się tak, ponieważ sandboxy są uruchomione na innym tierze wydajnościowym w Azure niż środowiska produkcyjne.
Wersja próbna BC nie nadaje się zatem do testowania wydajności rozwiązań w BC czy też samego BC. W celu przeprowadzenia testów wydajności na BC online, należy utworzyć dedykowane środowisko produkcyjne, tylko to zapewni dokładnie taką samą wydajność, jaką użytkownicy mogą później doświadczyć w rzeczywistym środowisku produkcyjnym.
Źródła zewnętrzne (w języku angielskim)
Środowisko testowe dla wersji próbnej BC online zostało dokładnie opisane w dokumentacji BC pod Get started → Try → Sign up for a free Dynamics 365 Business Central trial ↗. Są tam również sekcje poświęcone m.in.: pytaniom i odpowiedziom dla wersji próbnej BC, rozwiązywaniu problemów z rejestracją, przedłużania okresu próbnego oraz anulowania wersji próbnej.
Na temat wydajności środowisk sandboxowych BC online, warto przeczytać Manage environments ¶ Sandbox environments ↗ oraz Performance in Business Central Online ¶ Performance on sandbox environments ↗.
Środowisko demonstracyjne na CDX
Czym jest CDX
Microsoft CDX (Microsoft Customer Digital Experiences) to usługa pozwalająca na tworzenie środowisk demonstracyjnych do prezentowania możliwości biznesowego oprogramowania Microsoft klientom końcowym. CDX dostępny jest pod adresem: cdx.transform.microsoft.com ↗. W związku z takim właśnie przeznaczeniem usługi, możliwość utworzenia środowiska w tej opcji jest dostępne tylko dla Partnerów.
Sposób ten ma jednak znaczną przewagę nad innymi. W utworzonym środowisku będziemy mieli dostęp nie tylko do BC, ale do całej gamy usług Microsoftu. Tworzony jest osobny fikcyjny tenant na Azure (bez subskrypcji na usługi Azure, ale jest możliwość skorzystania z darmowej subskrypcji o wartości $200) dla fikcyjnej firmy o nazwie Contoso, zestaw fikcyjnych użytkowników w tenancie, konta e-mail dla tych użytkowników w Exchange Online, licencje Office E5, licencje Power Platform.
Mając tak przygotowanego tenanta i udostępnione konto administratora, należy jeszcze za jego pomocą zarejestrować wersję próbną Business Central (opisaną w rozdziale powyżej ¶ Wersja próbna BC), aby otrzymać licencje Business Central dla wersji próbnej (z możliwościami licencji Premium). Pod kątem samego BC, możliwości (i ograniczenia) są zatem dokładnie takie same jak przy rejestracji wersji próbnej BC pod klienta (opisanej w rozdziale powyżej ¶ Wersja próbna BC), ale tutaj nie na klienckim tenancie, a na fikcyjnym i do tego w pełni wyposażonym.
Dla kogo
Jest to więc idealna opcja dla Partnerów, którzy potrzebują Business Central we w pełni skonfigurowanym środowisku Microsoftu, aby móc przygotować na nim dopasowane do klienta demo i zaprezentować klientom (a raczej przyszłym klientom) szerokie możliwości BC, w tym wszelkie funkcjonalności integracji z innymi usługami Microsoft (Edit in Excel, Outlook Add-in, Teams, Power BI, Power Automate, Power Apps, Power Pages, OneDrive, Cash Flow Forecasts i inne funkcje ML w BC, możliwości funkcji AI korzystających z Copilot, itd.).
Instalowanie rozszerzeń
Podobnie jak w przypadku produkcyjnych środowisk BC online, również na środowiskach demonstracyjnych utworzonych na CDX, instalować możemy własne rozszerzenia PTE importując paczkę .app, a także rozszerzenia ISV wprost ze sklepu Microsoft AppSource ↗. Nie możemy natomiast wgrywać rozszerzeń ISV dla których posiadamy tzw. „runtime app” (aplikację skompilowaną w paczkę .app).
Rozszerzenia bez wersji próbnej lub okresu próbnego
W związku z powyższym, zainstalowanie na środowisku demonstracyjnym CDX rozszerzenia ISV, które w AppSource nie jest dystrybuowane na zasadach darmowej wersji próbnej lub okresu próbnego (zamiast tego na karcie aplikacji w AppSource występuje przycisk do pozostawienia informacji kontaktowych – Skontaktuj się ze mną) jest nieco utrudnione. Taki sposób dystrybucji w AppSource może być ewentualnie zasadny dla aplikacji wymagających szczególnej uwagi, na przykład aplikacji, które wymagają dodatkowej konfiguracji z zewnątrz lub aplikacji, które nie powinny być używane bez odpowiednich wskazówek od dostawcy. Aczkolwiek dla pozostałych przypadków, dostawcy ISV nie powinni stosować tej metody listingu aplikacji w AppSource.
Dla Partnerów w Polsce chcących utworzyć polskie środowisko demonstracyjne, jest to szczególnie dotkliwe, ponieważ rozszerzenia z polską lokalizacją, tj. Polish Localization (od IT.integro) czy Localization for Poland (od Companiala) są dystrybuowane właśnie w taki sposób.
Aby mimo to zainstalować tego typu aplikacje, należy sprawdzić jaki jest identyfikator aplikacji określony w manifeście aplikacji (w pliku app.json) – jest on widoczny m.in. w URL karty aplikacji w AppSource – a następnie użyć go do instalacji aplikacji wykorzystując admin center API (MS Learn ↗) lub nawet łatwiej, uruchamiając odpowiednio przygotowany bezpośredni URL (MS Learn ↗):
https://businesscentral.dynamics.com/<id-tenanta>/?noSignUpCheck=1&filter=%27ID%27%20IS%20%27<id-aplikacji>%27&page=2503gdzie <id-tenanta> należy zamienić na identyfikator tenanta środowiska CDX, na którym chcemy zainstalować aplikację, a <id-aplikacji> na identyfikator aplikacji z AppSource, którą chcemy zainstalować.
Długość życia i warunki użytkowania
Każdy użytkownik (koniecznie skojarzony z kontem Partnera) może utworzyć do 5 jednoczesnych środowisk demonstracyjnych z okresem życia 90 dni oraz 1 środowisko demonstracyjne z okresem życia 1 rok. Jeżeli potrzeba jest utworzenia kolejnego środowiska, należy usunąć jedno z poprzednich.
Aktualizacja: od kwietnia 2024 Microsoft zmienił (ograniczył) limity tworzenia środowisk dla Partnerów do 1 jednoczesnego środowiska demonstracyjnego z okresem życia 90 dni 😞.
Niezależnie od okresu życia środowiska demonstracyjnego, okres funkcjonowania samego BC na tym środowisku rządzi się własnymi prawami takimi jak przy wersji próbnej (patrz wyżej Wersja próbna BC ¶ Długość życia i warunki użytkowania).
Jak utworzyć środowisko
Podczas tworzenia środowiska demonstracyjnego w usłudze CDX jest kilka opcji, na które powinniście zwrócić uwagę i rzeczy, o których trzeba pamiętać w kontekście uruchomienia BC na tych środowisku. Opisuję je w osobnym poradniku: Jak utworzyć środowisko demonstracyjne na CDX.
Kontener Docker
Tło technologiczne
Jeżeli nie interesuje Cię tło techniczne, nie chcesz rozumieć czym dokładnie są kontenery, mniej więcej wiesz o co chodzi, ale chcesz się po prostu dowiedzieć jakie korzyści kontenery niosą w kontekście BC, pomiń sekcję poniżej ¶ Dla kogo.
Czym są kontenery?
Nieco upraszczając, jest to sposób na izolację aplikacji od głównego hosta (systemu operacyjnego naszego lokalnego komputera) jednocześnie pozwalając wyizolowanej aplikacji na korzystanie z zasobów sprzętowych hosta i jego systemu operacyjnego.
Dawniej, gdy chcieliśmy np. zainstalować NAV’a u siebie lokalnie na potrzeby testów czy przygotowania demo, ale nie chcieliśmy obciążać naszego własnego lokalnego systemu instalacją SQL Servera, NAS’a, komponentów .NET itd., mieliśmy możliwość wyizolowania takiego środowiska na maszynie wirtualnej. Trzeba było zainstalować wirtualizator (hypervisor) tj. VirtualBox, VMware Player, Microsoft Hyper-V lub inny, utworzyć nową maszynę wirtualną z wydzielonymi zasobami, zainstalować na niej system operacyjny, a na nim docelowe oprogramowanie. Poza bardzo dużym nakładem pracy i czasu, który musieliśmy poświęcić, problemem VM’ów było również to, że były potężnych rozmiarów – wszak zawierały cały osobny system operacyjny, własny zestaw sterowników, a dopiero na końcu wszystkie biblioteki i komponenty potrzebne do działania NAV, jak i samą aplikację.
Kontenery są odpowiedzią na powyższe problemy maszyn wirtualnych – każdy z kontenerów zawiera jedynie to co faktycznie jest potrzebne aplikacji, a nie ma tego nasz system lokalny. Korzysta z systemu operacyjnego hosta, ale jednocześnie w żaden sposób na niego nie wpływa (nie instaluje pakietów, nie zmienia rejestrów). Kontener jest więc o wiele lżejszy pod kątem zajętości miejsca na dysku, o wiele lżejszy pod kątem zasobów jakie potrzebuje do uruchomienia (nie ma potrzeby uruchamiania pełnego systemu w systemie, jak w przypadku VM), a także nieinwazyjny w stosunku do systemu operacyjnego. Nie musimy też poświęcać czasu na osobne instalowanie systemu operacyjnego, komponentów, a nawet samej aplikacji. Dodatkowym plusem jest to, że części wspólne siostrzanych kontenerów, tj. biblioteki, komponenty, potrzebne do działania aplikacji na kontenerach tego samego typu, nie muszą być powielane w każdym kontenerze i mogą być współdzielone!
Dla kogo
Możliwość utworzenia środowiska testowego BC na własnym komputerze będzie szczególnie atrakcyjna dla… właściwie dla każdego. Dla każdego, kto np. potrzebuje przetestować nową wersję BC w zakresie funkcjonalności core’owych (Base Application czy System Application), kto chce ustawić własne środowisko deweloperskie na potrzeby własne (np. nauki programowania w AL) lub projektu, lub kto po prostu chce „sprawdzić coś w standardzie”, a na dodatek chce to sprawdzić na konkretnej wersji.
Co do ostatniego… zdarza się przecież, że konsultanci potrzebują sprawdzić określone zachowanie systemu (w standardzie lub przy użyciu określonego rozszerzenia dedykowanego PTE lub rozszerzenia ISV) koniecznie na takiej samej wersji jaką obecnie ma klient (z dokładnością do numeru builda), ale z jakiegoś powodu nie można tego zrobić w środowisku produkcyjnym na kopii firmy, bazie testowej lub sandboxie.
Mało tego! Poza możliwością tworzenia kontenerów z BC w dowolnej wersji, mamy również możliwość utworzenia kontenera z Dynamics NAV w zakresie dowolnego builda wersji od NAV 2016 do NAV 2018.
Ograniczenia
Należy jednak pamiętać, że BC w kontenerze Docker’owym to samo BC i nic więcej. Logowanie zwykle metodą NavUserPassword, ewentualny certyfikat self-signed dla komunikacji HTTPS, możliwość instalacji własnych rozszerzeń PTE, możliwość instalacji rozszerzeń ISV, ale tylko tych dla których posiadamy runtime app (aplikację skompilowaną w paczkę .app).
Ograniczenia wynikają z tego, że całość działa całkowicie lokalnie, bez podłączenia do Microsoftowego tenanta czy Azure. W związku z tym, nie jesteśmy w stanie uruchomić niektórych funkcji systemu na kontenerowym BC (w tym np. części integracji z innymi usługami czy produktami Microsoftu wymagającymi działania w chmurze), ale w innych przypadkach ta niezależność i lokalność może być również pewną zaletą…
Konsultant jadąc „w teren” czy do klienta, może zabrać ze sobą skonfigurowaną aplikację BC czy spersonalizowane demo na swoim laptopie nie martwiąc się o dostępność i stabilność łącza internetowego, dostępność pulpitów zdalnych na serwerach firmowych, czy stan usług Microsoftu (chociaż to raczej nie powinno być zmartwieniem – podczas Directions EMEA 2023, Microsoft ogłosił, że globalny czas dostępności usługi BC online w ostatnim kwartale wyniósł 99,98%). Środowisko kontenerowe jest od nich całkowicie niezależne. Programista może z kolei pracować z kodem AL gdziekolwiek jest, również tam, gdzie nie ma stałego dostępu do Internetu czy nawet mobilnego zasięgu.
Czas do uruchomienia
BC w kontenerze jest najszybszym i najmniej inwazyjnym sposobem na postawienie sobie lokalnego środowiska do testów. Dzięki zaletom konteneryzacji wpływ instalacji na nasz system operacyjny jest znikomy.
Pierwszy działający kontener z BC jesteśmy w stanie utworzyć w około 30-90 minut (w zależności od prędkości łącza internetowego), natomiast każdy następny będzie tworzył się znacznie szybciej. Przy kolejnych kontenerach Docker będzie potrzebował ściągnąć jedynie brakujące elementy, korzystając z już wcześniej ściągniętych elementów wspólnych (np. SQL Server). Zatem czas uruchomienia kolejnych kontenerów BC może spaść nawet do kilku minut.
Jedynie zasoby naszego komputera (szczególnie pojemność dysku twardego i wielkość dostępnej pamięci RAM) są w stanie ograniczyć nam liczbę kontenerów, które w danej chwili możemy mieć uruchomione w swoim systemie.
Aktualizacje przy Docker Desktop
Do tworzenia kontenerów na naszym komputerze z systemem Windows konieczna jest instalacja aplikacji Docker Desktop jako czegoś w rodzaju panelu sterowania naszymi kontenerami. Docker Desktop utrzymuje stan kontenerów, jest to też miejsce z którego możemy nimi zarządzać: uruchamiać, restartować, zatrzymywać, usuwać, czytać logi, itd.
Jeszcze do niedawna każdorazowa aktualizacja aplikacji (a te wychodzą dosyć często) wiązała się z widmem tego, że wszystkie istniejące kontenery mogły po prostu przestać się uruchamiać (z brakiem jakiejkolwiek skutecznej metody na reanimację). Na szczęście od jakiegoś czasu sytuacja się już ustabilizowała i problem występuje sporadycznie. Moje kontenery działają już stabilnie od kilku miesięcy, ale na wszelki wypadek staram się nie aktualizować aplikacji Docker Desktop jeżeli nie muszę… (na wszelki W).
Uwaga na aktualizacje Windows
Należy jednak pamiętać, że to czego robić NIE wolno, to aktualizacja wersji systemu operacyjnego hosta – czyli naszego systemu operacyjnego Windows na komputerze.
Nie chodzi tutaj o pojedyncze aktualizacje systemu, które są wypuszczane dosyć często – te jak najbardziej można instalować (a te dotyczące bezpieczeństwa nawet trzeba) i nie należy obawiać się, że aktualizacje te zepsują nasze kontenery.
Problemem są natomiast aktualizacje zbiorcze, wypuszczane przez Microsoft raz lub rzadziej 2 razy w roku, które podwyższają wersję Windowsa. Na dzień pisania tego artykułu aktualna wersja Windowsa 10 to 22H2 ↗, natomiast dla Windowsa 11 aktualną wersją jest 23H2 ↗. Gdy wykonamy upgrade do nowszej wersji Windowsa, spowoduje to, że elementy środowiska kontenerowego (instalowane w chwili tworzenia kontenera pod konkretną wersję systemu), przestaną do siebie pasować, a w konsekwencji tego kontenery po prostu przestaną się uruchamiać.
Jak utworzyć kontener z BC
Na pierwszy rzut oka cały proces instalacji może wydawać się skomplikowany – najpierw instalacja aplikacji Docker Desktop, gdzie wcześniej musimy spełnić dosyć specyficzne wymagania, potem instalacja konsolowa BC-kowego kontenera za pomocą skryptów PowerShell’owych z wykorzystaniem osobnego modułu… Faktycznie nie jest to może tak proste jak byśmy chcieli, ale po kilku utworzonych kontenerach można nabrać w tym wprawy, a nawet przygotować sobie gotowca – skrypt który będziemy wykorzystywali za każdym następnym razem, co uprości proces do absolutnego minimum.
W osobnym poradniku opisuję krok po kroku w jaki sposób uruchomić BC w kontenerze: Jak uruchomić BC w kontenerze Docker.
Instalacja z obrazu DVD
Ostatnim z opisanych sposobów jest najbardziej klasyczna metoda polegająca na instalacji systemu (w wersji on-premises) wprost z płyty instalacyjnej systemu Business Central. Obraz płyty DVD możemy pobrać z zasobów Microsoftu (nie wymaga logowania kontem Partnerskim).
Wśród opcji dostosowania instalacji jest również możliwość instalacji SQL Server (w wersji Express) wraz z demonstracyjną bazą danych z danymi fikcyjnej firmy Cronus i demonstracyjną licencją.
Dla kogo
Na pewno dla administratora, który potrzebuje zainstalować BC on-premises na infrastrukturze serwerowej klienta pod docelowe środowisko produkcyjne, testowe czy deweloperskie. Natomiast czy jest to dobra opcja pod lokalne środowisko testowe na własne potrzeby…? Moim zdaniem nie.
Instalacja komponentów pod serwer aplikacji BC (w tym m.in. SQL Server czy IIS) na swoim własnym systemie operacyjnym, na którym pracujemy na co dzień jest jak strzał w kolano albo… włożenie sobie kija w szprychy podczas jazdy rowerem. Oczywiście chyba, że dokładnie wiemy co robimy, umiemy przydzielać pamięć aplikacjom i kontrolować usługi systemowe.
Taka instalacja szybko potrafi zjeść (pożreć) nasze zasoby, szczególnie pamięć operacyjną, ale i dyskową oraz na dłuższe chwile zajmować nasz procesor. Nawet jeżeli zdecydujecie się odinstalować całość (a raczej wszystkie komponenty całości po kolei), to w rejestrze systemowym pozostanie wiele zmian.
Więc czy jest jakiś sposób na instalację klasyczną, ale tak, aby była nieinwazyjna dla systemu? Tak, maszyna wirtualna. Jednak pod względem optymalizacji zasobów, czasu instalacji i wygody korzystania, maszyny wirtualne ustępują miejsca kontenerom. Ale o tym… napisałem już wyżej ¶ Czym są kontenery.
Zakończenie
Dotarłeś aż tutaj? Już za to należą Ci się brawa! ;) Mam nadzieję, że artykuł pomimo że przydługi, dostarczył Ci praktycznej wiedzy i wiesz już jakie są sposoby na utworzenie środowiska BC na potrzeby testowe lub demonstracyjne.
Jeżeli chcesz zagłębić się w temat jeszcze bardziej, zajrzyj do poradników gdzie omawiam krok po kroku jak utworzyć środowisko demonstracyjne na CDX oraz jak uruchomić BC w kontenerze na własnym komputerze.
Dzięki! 🙌
