Zmiana jest jednym z elementów stale obecnych w życiu każdego architekta. Na płaszczyźnie zawodowej obcujemy z nią każdego dnia, wielokrotnie rewidując nasze pomysły, koncepcje i rozwiązania. Stare architektoniczne porzekadło mówi, że do koncepcji nie należy się przyzwyczajać. Jak natomiast ta zawodowa mądrość przekłada się na sferę oprogramowania?
Jeśli jesteśmy posiadaczami Karty Multibim, co roku otrzymujemy nową wersję Archicada, a wraz z nią nowe funkcje i usprawnienia. Instynktownie chcemy pracować w najnowszej wersji, aby korzystać z wprowadzonych udogodnień. Proces projektowy jednak przeważnie nie koreluje z kalendarzem aktualizacji oprogramowania. Powstaje wtedy pytanie, czy i jak przeprowadzić tak zwaną migrację projektu Archicada do nowej wersji, aby nie narazić się na późniejsze problemy? Czy warto przeprowadzić migrację, kiedy projekt jest już mocno zaawansowany? Zapraszamy na pierwszy z cyklu artykułów, które wyjaśnią od podstaw proces migrowania projektów.
Migracja projektu Archicada to najogólniej rzecz biorąc proces przenoszenia projektu pomiędzy kolejnymi wersjami oprogramowania. Polega on na tłumaczeniu narzędzi i bibliotek, które mogą różnić się pomiędzy poszczególnymi edycjami. Każdy zapisany przez nas projekt ma w sobie zakodowaną wersję Archicada, w której został stworzony. Związane z tym zasady otwierania są następujące:
Powyższe przypadki dotyczą różnic w wersjach programu (porównaj wersje Archicada). Pamiętajmy jednak, że każda wersja Archicada posiada zwykle co najmniej parę aktualizacji, co również wpływa na możliwości otwierania plików.
Istotny jest zatem również aspekt tak zwanej kompilacji (ang. build) danej wersji oprogramowania. Przykładowo w trakcie pisania tego artykułu najnowszą kompilacją Archicada 25 w wersji Polskiej jest kompilacja 5010. Kompilacje zmieniają się wraz z zainstalowanymi aktualizacjami. Numer ten jest również zapisywany w pliku projektu. Należy pamiętać, że jeśli pracujemy w Teamworku i uwspólnimy na serwer Bimcloud projekt w wyższym numerze kompilacji, osoby mające niższy numer kompilacji nie będą mogły do niego dołączyć. Analogicznie jeśli dołączymy do projektu Teamwork o niższym numerze kompilacji, automatycznie nadpiszemy jego numer kompilacji na wyższy. Dlatego właśnie aktualizacje warto przeprowadzać równolegle na wszystkich stanowiskach.
Aby uporządkować wiedzę o migracji projektów podzielmy jej typy według dwóch podstawowych kryteriów. Pierwsze z nich wynika z rodzaju projektu i jest związane z faktem, czy pracujemy na projekcie indywidualnie, czy współpracujemy w ramach zespołu przy użyciu BIMcloud. Oba przypadki będą różniły się przebiegiem samego procesu migracji. Możemy zatem wyróżnić w tym aspekcie dwa podstawowe typy:
Drugim kryterium podziału jest kryterium związane z kierunkiem zmian. Odpowiada ono na pytanie, czy dany projekt chcemy otworzyć w nowszej, czy w starszej wersji programu. Otwieranie nowych plików w starszych wersjach będzie zdecydowanie bardziej ograniczone. Wyróżniamy tutaj dwie możliwe ścieżki:
Szczegółowo przebieg różnych rodzajów migracji omówimy w kolejnych artykułach, jednak na początek odpowiedzmy sobie na pytanie, dlaczego w ogóle jest to trudny proces? Każda wersja Archicada oznacza nowe funkcje oraz zmiany w bibliotekach programu. Konieczność przeprowadzania migracji, wynika z tłumaczenia starych elementów na nowe i odwrotnie.
Przykładowo narzędzie belka zostało przebudowane w Archicadzie 23. Jak zatem program ma przetłumaczyć belki utworzone przy pomocy wcześniejszej konstrukcji narzędzia? Podobnie rzecz ma się z bibliotekami. Obiekty otrzymują swoje nowe, ulepszone lub poprawione wersje. Czasami są to drobne detale, jednak musi zostać przeprowadzony proces podmiany jednych obiektów na drugie przy pomocy tak zwanych bibliotek migracji.
Czasami jednak zmiany zachodzące w programie są na tyle istotne, że proste przetłumaczenie jednego elementu na drugi, nie może zostać prosto przeprowadzone. W takich sytuacjach musimy zachować szczególną ostrożność i przejrzeć tabelę migracji, aby przewidzieć, gdzie mogą pojawić się potencjalne kłopoty i podjąć decyzję, czy w ogóle migrować projekt.
Odpowiedź na to pytanie brzmi niestety: to zależy. Przy zaawansowanych projektach, które są na końcowym etapie ich tworzenia, może to nie mieć sensu. Jeśli nie potrzebujemy pilnie konkretnej funkcjonalności z nowszej wersji, aby ukończyć projekt, potencjalne problemy mogą przerosnąć zyski.
Z kolei projekty będące na początkowym etapie opracowania lub oczekujące na rozpoczęcie kolejnego etapu po wymodelowaniu koncepcji, zdecydowanie warto migrować, aby skorzystać z benefitów płynących z najnowszego oprogramowania.
Każdy przypadek powinien jednak zostać poprzedzony czterema podstawowymi krokami:
Takie działanie pozwoli Państwu uniknąć późniejszych kłopotów, które mogą objawić się w różnych miejscach projektu. Aby dowiedzieć się jak poradzić sobie z migracją, zapraszamy do śledzenia kolejnych artykułów z tej serii w najbliższej przyszłości. Omówimy w nich, w jaki sposób bezpiecznie migrować projekty. Już wkrótce może się to okazać istotne w kontekście nadchodzącej wielkimi krokami premiery Archicada 26.