Kompletny przewodnik po strategiach migracji technologii: (Część 1 – Wprowadzenie)

Wraz z rozwojem nowych technologii każdego dnia, stare technologie stają się przestarzałe. Aby przetrwać na dzisiejszym rynku, każda firma musi być na bieżąco. Każda firma, która dostarcza swoim użytkownikom różne usługi i platformy, musi być gotowa do radzenia sobie z codziennymi technologiami modernizacji. W takich momentach pojawia się migracja. Firma zawsze może przejść na nową, lepszą platformę. Teraz można by pomyśleć, co to jest migracja? Odpowiedź jest krótka i jednocześnie nieco złożona. Migracja to bardzo proste określenie dla nietechnicznych mugoli, co oznacza migrację z jednego miejsca do drugiego. Ale jeśli chodzi o czarodziejów technologii takich jak my, ma to nieco inne znaczenie. Zróbmy więc pierwszy krok i zrozummy migrację w kategoriach technicznych. Migracja oznacza przejście z obecnej platformy na inną. W większości przypadków migracja odbywa się na lepszą platformę, ponieważ zapewnia ona lepsze środowisko pracy i doświadczenie użytkownika. Czasami obawy dotyczące bezpieczeństwa mogą również prowadzić do migracji. Istnieje wiele rodzajów migracji, a oto niektóre z najczęściej poruszanych tematów migracji, o których możesz chcieć wiedzieć:

1. Migracja technologii
2. Migracja technologii front-end
3. Migracja technologii zaplecza
4. Strona zbudowana przez CMS Migracja
5. Migracja bazy danych
6. Migracja domeny i serwera hostingowego

Migracja pod względem technicznym to znacznie szerszy temat, niż możesz sobie wyobrazić. Trochę trudno jest ogarnąć wszystkie tematy migracji i jej rodzaje w jednym blogu. Stąd temat ten podzielony jest na różne części, wyjaśniające znaczenie migracji wraz z jej rodzajami. Możesz je przeczytać w nadchodzących blogach.

Migracja jest kluczowym zadaniem i jeśli nurtują Cię pytania, takie jak kiedy i jak przeprowadzić migrację, określenie zakresu migracji itp., możesz kontynuować czytanie tego bloga, aby oczyścić umysł.

Dlaczego istnieje potrzeba migracji?

• Kiedy Twoja obecna technologia, nad którą pracowałeś tak długo, nie jest już w stanie sprostać oczekiwaniom stawianym przez Twój biznes.
• Gdy technologia staje się przestarzała, a wsparcie dostawcy nie jest również dostępne dla przestarzałej wersji.
• Kiedy Twoi klienci są dla Ciebie ważni i musisz być na szczycie swojej branży.
• Kiedy nie chcesz już ogromnych kosztów licencjonowania obecnego stosu, przechodząc na platformę open source.

W tym czasie migracja będzie najlepszą opcją. Migracja to złożony proces i wymaga dużo planowania.

Pierwszym krokiem w procesie migracji jest ustalenie definicji i podstawowych zasad, które pozwolą na płynne przeprowadzenie procesu migracji. W zależności od wymagań projektu:

• Najpierw musisz przeanalizować aktualny stan swojego projektu lub aplikacji, która wymaga migracji.
• Przygotujesz mapę drogową obliczonych ryzyk i możliwych rozwiązań, które mogą pojawić się podczas migracji.
• Musisz dobrać odpowiednią technologię, która spełni wszystkie wymagania projektu.
• Następnie będziesz potrzebować odpowiedniego planu przeprowadzenia procesu migracji
• Na koniec, po zakończeniu procesu migracji, sprawdź, czy aplikacja działa zgodnie z oczekiwaniami na nowej platformie, czy nie.

Jest kilka punktów, o których należy pamiętać przed przejściem do fazy planowania migracji.

• Zdecyduj budżet projektu i harmonogram przed fazą planowania migracji w zależności od problemu biznesowego.
• Wybierz działający model, taki jak ustalanie stawek godzinowych lub tygodniowych dla każdego nowego klienta, który chce przeprowadzić migrację z dowolnego istniejącego systemu do nowego. Istnieje kilka szarych obszarów, które omówimy w kolejnych blogach i można je napotkać dopiero, gdy nowy zespół programistów rozpocznie pracę. Migracja nie może być traktowana ze stałą szacunkową pracą dla żadnego nowego zespołu.
• Jeśli klient jest osobą nietechniczną, zawsze zaleca się podpisanie umowy określającej zakres migracji przed fazą planowania migracji lub klient może również zatrudnić kontraktowego kierownika projektu, który może współpracować z zespołem programistycznym.

Zdefiniuj zakres migracji

W przypadku każdego zespołu deweloperskiego pracującego nad projektem migracji, który nie jest świadomy obecnego systemu, klient powinien spędzić czas z nowym zespołem, aby upewnić się, że zespół rozumie przepływ systemu. Nowy zespół musi poświęcić wystarczająco dużo czasu na przeanalizowanie istniejącego systemu i opracowanie planu migracji. Tymczasem klient zawsze może poruszyć jakie problemy biznesowe napotyka przy obecnym systemie.

Aby zdefiniować zakres projektu, klient musi udostępnić szczegółowe wymagania dotyczące projektu, aby pomyślnie zakończyć migrację. Deweloperzy i klient muszą być na tej samej stronie z planem migracji i należy przeprowadzić odpowiednią dyskusję na temat wszystkich aspektów migracji, aby zabezpieczyć się przed wszystkimi przyszłymi problemami.

Czasami może się zdarzyć, że zespół programistów nie tworzy szczegółowej dokumentacji logiki biznesowej odwzorowanej w technologii backendowej. Jeśli migracja jest wykonywana przez ten sam zespół, nie spowoduje to większego problemu, ale gdy migrację wykonuje nowy zespół, dokumentacja jest naprawdę ważna. Dlatego wysoce zalecane jest posiadanie szczegółowej dokumentacji logiki biznesowej.

Upewnij się, że jasno zaznaczysz w swoim dokumencie zakresu, że każdy rodzaj pracy poza pierwotnym zakresem będzie uważany za pracę dodatkową i będzie podlegał opłacie premium, w tym oryginalnemu budżetowi. Pomoże to zapobiec możliwym pełzaniom zakresu, które mogą wystąpić w przyszłości.

Jak zaspokoić Scope Creeps?

Zanim zrozumiemy obsługę Scope Creeps, pozwól, że opowiem Ci o pojęciu Scope Creep i jego wpływie na zespół programistów. Pełzanie zakresu jest wynikiem zmieniających się wymagań technicznych, które są wprowadzane w projekcie bez wydłużania harmonogramu lub zwiększania budżetu projektu.

Istnieje wiele powodów, które powodują pełzanie zakresu, a niektóre z bardzo powszechnych powodów są wymienione poniżej, aby uniknąć tych pełzających w migracji projektu.

• Niezrozumienie wymagań projektu jest jedną z najczęstszych przyczyn pełzania zakresu, która stwarza problemy programistom w późniejszych fazach migracji.
• Unikaj pułapek, takich jak częste informacje zwrotne od użytkownika końcowego. Nie ma sensu zabawiać wszystkich punktów zwrotnych. Ale to nie tak, że w ogóle nie przyjmujesz informacji zwrotnych. Wybieraj tylko te najbardziej powtarzalne i spektakularne.
• Zgoda na wszystkie prośby o zmianę może na początku pomóc w budowaniu pozytywnej relacji, ale skończy się niezadowoleniem klienta z projektu. Więc zanim zgodzisz się na informację zwrotną lub prośbę o zmianę, upewnij się, że jest to priorytet i pilność, i poinformuj klienta końcowego o wpływie na podejmowane wysiłki.
• Istnieje niezliczona ilość innych czynników, które wpływają na zakres projektu, który nie jest pod Twoją kontrolą, takie jak nowe funkcje dodane do istniejącej technologii, zmiany ekonomiczne na rynku, sytuacje awaryjne itp. Dlatego lepiej przygotować się na te możliwości.

Teraz, gdy zrozumiałeś termin Scope Creep i znasz możliwe przyczyny, które się kończą, jedno jest jasne, że plan zapobiegawczy jest najlepszym możliwym sposobem na uniknięcie wszelkich wkradnięć w zakresie twojego projektu migracyjnego. Niezależnie od wszystkich dokonanych planów, nie ma możliwości dokładnego przyjęcia każdego przyszłego żądania zmiany funkcji w wymaganiach projektowych. W takich chwilach dokumentacja zakresu migracji może Cię uratować.

Wybór stosu technologicznego

Jako programista masz przed sobą wiele opcji, takich jak MongoDB do MySQL, AngularJS do React, stos MEAN do stosu LAMP i serwery hostingu w chmurze, takie jak Amazon AWS, do serwerów do samodzielnego hostingu, takich jak Apache. Te opcje mogą zmylić każdego. Zatem to programista jest odpowiedzialny za wybór planowanego stosu technologicznego do migracji. Musisz być również przygotowany na każdą przyszłą potrzebę.

W przypadku, gdy chcesz wybrać platformę migracyjną i nie rozumiesz jasno wymagań dla nowej platformy, istnieje opcja, w której możesz zatrudnić architekta rozwiązań, który ma doświadczenie i pracował w złożonych systemach. Najlepiej byłoby, gdyby była to zewnętrzna firma konsultingowa, więc każdy klient może sam zatrudnić architekta rozwiązań lub zapłacić rozwijającej się firmie. Należy to wynegocjować i uzgodnić zadanie, które należy wykonać przed planowaniem fazy migracji.

Musisz mieć pewność, że funkcje nowej platformy są wypróbowane i przetestowane. Zdecydowanie nie chcesz być pierwszym, który dowie się o wadach i pułapkach nowej platformy. Musisz upewnić się, że wszystkie dane są bezpiecznie zachowane, a inne funkcje nie wymagają wielu modyfikacji po migracji na nową platformę. Migracja jest złożonym procesem, ale jeśli zostanie wykonana prawidłowo, może dać nowy początek starej, przestarzałej technologii.

Upewnij się, że sprawdzasz, czy obecny system ma DevOps, czy nie. DevOps pomaga skrócić cykl życia rozwoju systemu i zapewnia ciągłość dostarczania. Jeśli obecny system korzysta już z tych narzędzi, możesz przejść do zaktualizowanej wersji lub kontynuować to samo. Zawsze zaleca się korzystanie z jakiegoś narzędzia CI/CD, ponieważ sprawia to, że proces migracji jest nieco łatwy i systematyczny dla programistów. Ponadto zespół programistów powinien postępować zgodnie ze ścisłym podejściem do przeglądu kodu i wypychania kodu, na przykład. Model GitFlow lub GitHubFlow.

Po zapoznaniu się z wymaganiami projektu, zakresem migracji i stosem technologicznym możesz łatwo wybrać lepszy zamiennik dla swojej platformy. Istnieją różne typy migracji i zanim przejdę do przodu, chciałbym wyjaśnić jedną rzecz, że nie każda migracja jest taka sama i każda z migracji wymaga odpowiedniego planowania i wykonania. Migracja i jej rodzaje to znacznie szersze tematy, więc kontynuacją tego bloga są 3 różne części, w których można uzyskać szczegółowe informacje o każdej migracji. W nadchodzącym blogu porozmawiamy o migracji technologii i jej typach. Bądźcie na bieżąco!