שדרוג PostgreSQL ללא השבתה: Blue/Green, רפליקציה ותוכנית חזרה עבור בסיסי נתונים של ERP בסביבה פרודוקטיבית

שדרוג PostgreSQL ללא הפסקת שירות נשמע בתחילה כהבטחה מעולם הענן. במציאות של מסד נתונים ERP פרודוקטיבי זו קודם כל דיסציפלינה: יש לגרום לכך שעקביות הנתונים, התנהגות הממשקים, ריצות אצווה, הדיווח, ההרשאות ותהליכי התפעול ישתלבו באופן שהמעבר בגרסה יהיה רגע החלפה מבוקר. את המונח «ללא הפסקת שירות» יש להבין לעתים נדירות כמוחלט. במעשה הדבר פירושו: אין הפרעה ניכרת למשתמשים, אין Rollbacks בלתי מתוכננים, אין נעילות שנמשכות שעות — ומעל לכל קיים נתיב חזרה שעובד באמת.

מאמר זה ממקם את מסלולי השדרוג הטיפוסיים ל־PostgreSQL בסביבות ERP — עם Blue/Green, שִכפול (פיזי ולוגי) ותוכנית חזרה שלא קיימת רק על הנייר. המוקד מושם במתכוון על התפעול ושאלות ההחלטה: איזו ארכיטקטורה נחוצה? היכן טמונים הסיכונים? אילו עבודות מקדימות גוזלות זמן? וכיצד נמנעים ממצבים שבהם שדרוג נכשל בעקבות נושאים שוליים כמו דרייברים, שרשראות עבודות או אי־בהירות לגבי בעלות על הנתונים?

למה מסדי נתונים של ERP בעייתיים במיוחד בעת שדרוג

מערכות ERP מאופיינות בעומסי OLTP (Online Transaction Processing), כלומר מותאמות להרבה עסקאות קצרות: כתיבת מסמכים, רישום תנועות מלאי, חישוב מחירים, רישום תשלומים. עסקאות אלה נשענות על ציפיות ברורות: השיהוי חייב להיות יציב, נעילות (Locks) אינן צריכות להסלים, והמערכת חייבת להישאר צפויה בשיאי עומס.

שדרוג PostgreSQL נוגע בדיוק ליציבות הזו — גם אם היישום עצמו לא משתנה. הסיבות כוללות בין השאר:

• שינויים באופטימייזר השאילתות (Planner): שאילתות עלולות לבחור פתאום תוכניות ביצוע שונות. זה אינו „שגוי“, אבל תחת עומס זה עלול ליצור נקודות חמות חדשות.
• שינויים בפרמטרים ובברירות מחדל: ערכי קונפיגורציה או התנהגותם כברירת מחדל משתנים בין גרסאות Major. זה נוגע למשל ל־Autovacuum, WAL (Write-Ahead Log — יומן הכתיבה המוקדמת, יומן העסקאות) או ל־work_mem/הגדרות זיכרון.
• נושאי דרייבר ופרוטוקול: גרסאות ODBC/JDBC/Npgsql, פרמטרי SSL/TLS, אימות (למשל SCRAM מול MD5) ושרשראות תעודה הם לעתים חסמים מוסתרים.
• אקו־סיסטם של ממשקים: ERP נדיר כ“רק יישום אחד“. Reporting, EDI, Webservices, ETL/BI, ניהול מסמכים ואינטגרציות אצווה ניגשים למסד הנתונים — ישירות או בעקיפין.

המסקנה: שדרוג הוא לא סתם שינוי במסד הנתונים. זה שחרור מתואם הכולל יישום, תפעול ומערכות סמוכות. לכן Blue/Green ושכפול שווים הרבה: הם מפרידים את המעבר הטכני מהסיכון של חלון תחזוקה ארוך.

הגדרת יעדים ברורה: «ללא הפסקת שירות» לא אומר «ללא החלפה»

לפני בחירת ארכיטקטורה כדאי להגדיר יעדים בבירור לפי מדדי תפעול:

• RTO (Recovery Time Objective): כמה מהר מסד נתוני ה־ERP חייב להיות זמין ויציב לאחר כשל?
• RPO (Recovery Point Objective): כמה נתונים (טווח זמן) מותר שיאבדו בתרחיש הגרוע ביותר? בהגירות אמיתיות ללא השבתה המטרה לעתים קרובות היא RPO≈0.
• חלון תחזוקה: האם קיים „חלון“ קטן (למשל כמה דקות) למעבר (Cutover), או שאין כלל? ב־ERP מעבר בדרך כלל אפשרי אם הוא ניתן לתיזמון (להימנע ממעברים בזמן החלפת משמרות או סוף חודש).

מטרות אלה קובעות האם ניתן לעבוד עם רפליקציה בתוספת Cutover או שמבחינתכם נדרשים גם מנגנונים לניתוק הכתיבה (לדוגמה Queueing בממשקים). מי שנותר לא חד כאן ישלם מאוחר יותר בצורת אימפרוביזציה ב-Go-live.

Blue/Green für PostgreSQL: Prinzip, Nutzen, typische Stolpersteine

Blue/Green משמעותו: שתי סביבות מלאות קיימות במקביל. „Blue“ היא הייצור, „Green“ היא הגרסה החדשה. היתרון המכריע אינו רק היכולת להחליף, אלא היכולת לבצע בדיקות בתנאים ריאליסטיים: Green ניתן לבדוק עם נתונים קרובים לייצור, ממשקים אמיתיים וניטור אמיתי, לפני שמשתמשים מבצעים מעבר.

עבור PostgreSQL בהקשר ERP, Blue/Green בדרך כלל כולל:

• אשכול PostgreSQL נפרד (Green) על Hosts/VMs חדשים או מופעים נפרדים
• פרמטרי רשת ואבטחה זהים (Firewall, TLS, DNS-Auflösung, Service-Accounts)
• העברת נתונים מוגדרת (העתקה ראשונית + Delta)
• מנגנון Cutover (DNS-/VIP-Umschaltung, Connection-String-Switch, Proxy)

מה Blue/Green מספק לכם תפעולית בפועל

בפועל מדובר בשלושה היבטים שעושים את ההבדל:

• חזרה אחורה מהירה: במקרה של כשל אתם מחזירים חזרה, במקום לנסות לתקן שדרוג „לאחור“.
• הפחתת סיכון באמצעות אימות מוקדם: Green יכול לקבל בדיקות ביצועים ותפקוד, כולל עומס טיפוסי של ERP (ריצות אצווה, הדפסה, גלי רישום).
• הפרדה ברורה בין סיכוני מסד נתונים וסיכוני יישום: כשה-Green פועל, רבות מהלא-ידועות כבר נבדקו (דרייברים, אימות, Extensions, פרמטרים).

מקרי שגיאה נפוצים ב-Blue/Green

רוב הכישלונות של Blue/Green אינם ברעיון עצמו אלא בפרטים:

• תלויות לא שלמות: כלי דיווח או אינטגרציות פונים „קשות“ אל ה-host הישן (IP, Alias, Zertifikat-Pinning). בעת ה-Cutover הם נתקעים.
• אחריות על ממשקים לא ברורה: אף אחד לא מרגיש אחראי לכך שכל ה-Consumer יעברו או לפחות ייבדקו.
• חוסר אימות נתונים: „הנתונים מועתקים“ אינו אומר שכל ההיבטים Fachlich תקינים (למשל רצפים/זהויות, חותמות זמן, לוגיקת ספרי-משנה).

Replikation als Upgrade-Werkzeug: physisch vs. logisch

עבור שדרוג PostgreSQL ללא זמן השבתה, שכפול הוא בדרך כלל המנגנון המרכזי לשמירה על נתונים במקביל. PostgreSQL מציע לכך גישות שונות עם פשרות שונות. חשוב: „Replikation“ ist nicht automatisch „Hochverfügbarkeit“. Für Upgrades nutzen Sie Replikation als גשר מיגרציה.

שכפול פיזי (Streaming Replication): מהיר, קר לרמת המכונה

שכפול פיזי עובד על רמת WAL: Der Standby bekommt das Transaktionsprotokoll und spielt es nach. זה ביצועי ויציב, אך עם חטא מרכזי לשדרוגי Major: בדרך כלל Primary und Standby צריכים להתאים לאותה גרסת Major. לכן בקפיצה בגרסה כגון PostgreSQL 13 ל‑16, שכפול פיזי מסייע בעיקר בתוך אותה גרסה (HA, Wartung), ולא כנתיב ישיר לשדרוג Major.

תועלת פרקטית בפרויקט שדרוג קיימת עדיין אם תשתמשו בשכפול פיזי כרשת ביטחון במערכת ה“כחולה“: אפשר לפני ה‑Cutover לוודא שהייצור הקיים רדונדנטי, בזמן שאתם בונים במקביל את ה“ירוקה“.

שכפול לוגי: העברת דלתא באמצעות פרסומים/מנויים

שכפול לוגי מעביר שינויים ברמת הטבלאות (INSERT/UPDATE/DELETE) ולכן מתאים לשדרוגי Major, מאחר ש‑Publisher ו‑Subscriber יכולים להיות בגרסאות Major שונות (תוך שמירה על התאימות המתאימה). עבור מסדי נתונים ERP זה לעתים הדרך הפרקטית ביותר לחלון החלפה מינימלי.

תכונות טיפוסיות שיש לתכנן:

• צילום מצב התחלתי + שינויים שוטפים: מאגר הנתונים מועתק בהתחלה ולאחר מכן השינויים נגררים.
• DDL אינו מועבר אוטומטית: שינויים בסכמה (DDL, כלומר טבלאות/עמודות/אינדקסים) אינם משוכפלים כמו שינויים בנתונים. לשדרוגים זה בדרך כלל מקובל, כי הסכמה לרוב נשארת זהה – אך הרחבות, תפקידי משתמש והרשאות צריכים לעבור מיגרציה באופן מודע.
• נושאי Sequence/Identity: רצפים (למשל עבור מספרי מסמכים) קריטיים ב‑ERP. בהתאם להגדרה יש לוודא שמצבי הרצפים יועברו בקונסיסטנטיות וימשיכו כראוי אחרי ה‑Cutover.
• חוסר קונפליקטים: במהלך שלב השכפול יש לכתוב רק מצד אחד. אחרת ייווצרו קונפליקטים שקשה לטפל בהם בתפעול ERP.

נתיב השדרוג בשטח: מתודולוגיה אמינה

ללא תלות בכלי הספציפי, שדרוג שממזער זמן השבתה בסביבות ERP בדרך כלל מתבצע בשלבים ברורים. מבנה פרקטי הוא:

1) ניתוח מקדים: מה באמת צריך לעבור?

כאן לא מדובר ב„Installiere PostgreSQL X“, אלא בתלויות:

• הרחבות (למשל לחיפוש טקסט מלא, עבודות, סוגי נתונים מיוחדים): אילו פעילות בייצור, ואילו קיימות מטעמי היסטוריה?
• Auth und Rollen: תפקידי גישה מקומיים, חיבור LDAP/AD, SCRAM, אימות באמצעות תעודות. ייצוא תפקידים וזכויות הוא שלב עבודה נפרד.
• Jobs und Batchläufe: האם ה-Scheduling מתבצע מחוץ למערכת (למשל באמצעות Jobserver) או בבסיס הנתונים (למשל דרך הרחבות)? אילו משימות קריטיות בזמן cutover (עיבוד לילה, Faktura, MRP)?
• Consumer-Landschaft: מי קורא/כותב? ERP-Backend, פורטלים אינטרנטיים, שירותי אינטגרציה, BI/ETL, חיבורי שותפים, DMS, ניטור.

מפת יישומים פשוטה אך יעילה היא Artefakt שימושי: מסד נתונים במרכז, חצים לכל המערכות כולל בעלים ושיטת המעבר (DNS, קונפיגורציה, Secret, Proxy). זה מונע שה-Cutover ייכשל בגלל „קוראים“ שנשכחו ופתאום מתקבלים עבורם timeout.

2) Green aufbauen: nicht nur Datenbank, sondern Betriebsfähigkeit

Green משמעותי רק כאשר הוא „אמיתי תפעולית“. לכך שייכים:

• Monitoring (מטריקות, לוגים, אזעקות): אותה ניראות כמו ב-Blue, אחרת ה-Go-live יהיה עיוור.
• Backup/RESTore: הגיבויים על Green חייבים לפעול, כולל בדיקת שחזור (לפחות בדיקות דגימה). רק כך ברור שבמקרה של שגיאה לא תפסידו פעמיים.
• Security-Parität: קונפיגורציית TLS, Cipher, שרשרת תעודות, כללי HBA (Host-Based Authentication), חומת אש. „להקשיח מאוחר יותר“ עלול להתנקם בעת ההעברה.
• Performance-Basis: השהיית אחסון, IOPS, CPU, RAM. שדרוג הוא זמן מתאים לתקן מחלקות אחסון בעייתיות או פרופילי VM מיושנים.

3) Datenübernahme: initiale Kopie und Delta-Phase

בעבור מסדי נתונים גדולים של ERP, ההעתקה הראשונית היא לרוב הצעד הארוך ביותר. אין צורך שהיא תתבצע במסגרת חלון התחזוקה אם תנתקו אותה כהלכה. קריטי שהשלב הדלטא (רפליקציה) ירוץ בצורה יציבה ויורד ונבדק: Lag, שגיאות, שינויים ממתינים.

מבחינה תפעולית חשוב: הגדרו ערכי סף שממתי בכלל תבצעו את ה-Cutover. אם Green תמיד מאחר, המעבר אמנם אפשרי, אך אתם מעבירים את הבעיה למערכת החיה.

4) Validierung: fachlich und technisch, ohne Perfektionismus

ולידציה אינה פרויקט בדיקה של חודשים, אך היא יותר מ-„SELECT COUNT(*)“. בסביבת ERP הבדיקות הבאות עובדות היטב:

• בדיקות דגימה בטבלאות קריטיות: פתחים פתוחים, מלאי, כותרות/שורות מסמכים, טבלאות קביעת מחיר, Debitor/Kreditor.
• השוואות אגגרטיביות: סכומים על פני פרקי זמן מוגדרים (Umsatz, כמויות) כדי לזהות סטיות משמעותיות במהירות.
• מדדים טכניים: מצב אינדקסים וסטטיסטיקות, פעילות Autovacuum, Replikations-Lag, מגבלות חיבורים, השהיות שאילתות.

חשוב להחליט מה באמת נדרש לאבחנה. שדרוג אינו Release פונקציונלי. המטרה שלכם להוכיח: אותם נתונים, אותו התנהגות, ביצועים יציבים. לשם כך מספיקים נקודות בדיקה מהימנות ושחזוריות.

5) Cutover: der Umschaltmoment muss wie ein Runbook funktionieren

ה-Cutover עצמו נדיר שיהיה מורכב, אך הוא רגיש לזמנים. Runbook טוב מתאר לא רק צעדים, אלא גם נקודות בדיקה וקריטריוני עצירה. מרכיבים טיפוסיים:

• לשלוט על עצירת כתיבה: או דרך מצב תחזוקה של היישום או דרך חסימה טכנית (למשל לנתק חיבורים של תפקידי כתיבה). המטרה: אין Writes חדשים על Blue בשלב האחרון.
• להביא את הרפליקציה ל“אפס“: להמתין עד ש-Green קלט את כל השינויים (RPO≈0).
• החלפת האפליקציה: מחרוזות חיבור, DNS, VIP, כלל פרוקסי. חשוב: עקביות עבור כל הרכיבים, לא רק עבור ה‑ERP‑Backend.
• בדיקות Smoke: התחברות, פתיחת נתוני יסוד, רישום אסמכתא, דוח טיפוסי, פינג לממשקים. קצר, אך בעל משמעות.

תוכנית חזרה (Rollback) ללא אשליות: מה תוכלו באמת להחזיר אחורה

תוכנית החזרה היא החלק שאנשים מעדיפים „לא להזדקק לו“. בדיוק בגלל זה היא חייבת להיות קונקרטית. ב-Blue/Green-Setups הליבה של החזרה היא העברה חזרה אל Blue. אבל: ברגע שאחרי Cutover מתבצעים כתיבות פרודוקטיביות על Green, „חזרה“ הופכת לבעיה מקצועית, אם Blue בינתיים לא קיבל גם הוא את כל הכתיבות.

אפשרויות Rollback והשלכותיהן

• Rollback מיידי לפני כתיבות פרודוקטיביות: מקרה אידיאלי. אם לפני שחרור המשתמשים תגלו שמשהו אינו תקין ביסודו, ניתן להחזיר את המערכת ללא קונפליקטים בנתונים.
• Rollback לאחר מספר כתיבות: אפשרי, אך רק עם אסטרטגיה ברורה: או רישום מחדש ידני (מבחינה מקצועית) או שכפול נגד-זמני/הסבת דלתא זמנית (מבחינה טכנית), שבדרך כלל אינו נטול קשיים בתהליכי ERP.
• לא Rollback, אלא „Fix forward“: אם Green כבר כותב פרודוקטיבית ומצב הנתונים שם הוא ה‑“Single Source of Truth“ החדש, החזרה אחורה לעיתים קרובות מסוכנת יותר מאשר ייצוב מכוון קדימה. יש לקבל אפשרות זו מראש.

לכן תוכנית חזרה אמינה מציינת במפורש:

• עד מתי ה‑Rollback נחשב „בטוח“ (חלון זמן או שלב ב‑Runbook)
• אילו קריטריוני עצירה חלים (למשל: כישלון ב‑Smoke-Test, שגיאות בממשקים, סכומים לא הגיוניים)
• כיצד מתנהלת התקשורת ואישורים (מי מחליט, מי מודיע)

חשוב יותר מה‑Rollback: ה„תפעול חירום“ לממשקים

בנופי ERP הממשקים הם הסיבה השכיחה יותר למצבים קדחתניים לאחר Cutover. כאשר חיבורי שותפים או שירותי אינטגרציה פנימיים מפסיקים לספק פתאום, דרוש לכם תפעול חירום: בופרים ביניים (Queues), כללי אתחול מחדש, אסטרטגיות Retry ברורות. „Retry“ חייב להיות אידמפוטנטי (ניתן לחזור עליו מבלי ליצור רישום כפול). זו אינה פונקציה של מסד נתונים, אלא עיצוב של היישום והאינטגרציה — אבל היא קובעת האם תוכלו להשיג שדרוג ללא עצירת שירות בפועל.

ביצועים ויציבות לאחר השדרוג: מדוע 48 השעות הראשונות קריטיות

רבים מהצוותים רואים את השדרוג כ„גמור“, ברגע שה‑Cutover הושלם. בפועל מתחילה אז תקופה שבה פרופילי העומס, התנהגות המטמון ו‑Autovacuum מתייצבים. אמצעים טיפוסיים שהוכיחו את עצמם:

• ניטור צפוף ב‑48 השעות הראשונות: שהיית שאילתות, נעילות, זמני המתנה ב‑I/O, נפח WAL, ריצות Autovacuum.
• זיהוי רגרסיות בתכניות: שאילתות בודדות שהיו „בסדר“ קודם יכולות לשלוט אחרי השדרוג. כאן עוזרות רשימות Top-Query והבנה ברורה מי רשאי לכוונן ביצועים (DBA מול צוות היישום).
• לצפות ב-Reporting/ETL בנפרד: כלים בעלי עומס קריאה הם לעתים הראשונים שיגרמו לבעיות (שאילתות ארוכות, תכניות חדשות). Read Replicas יכולים לעזור, אך הם חייבים להשתלב בקונספט הכולל.

עבור הנהלת ה-IT חשוב: תכננו את הייצוב הזה כחלק מה-Change. שדרוג ללא Downtime אינו „ללא מאמץ“, אלא מאמץ הנעשה בזמן הנכון ובצורת סיכונים מבוקרת.

החלטות ארכיטקטוניות טיפיות סביב ERP: DNS, מחרוזות חיבור, פרוקסים

ה-Cutover יהיה מסודר יותר ככל שנקודת ההחלפה תהיה חד-משמעית יותר. וריאנטים נפוצים:

• DNS-Alias (למשל db-erp.prod): פשוט, אבל TTL (Time To Live) וקאש בצד הלקוח יכולים להאריך את זמני ההחלפה. אצל חלק מהדרייברים קאש DNS עלול להיות עקשן באופן מפתיע.
• כתובת IP וירטואלית / Load Balancer: ההחלפה טכנית מהירה, אך אתם זקוקים לקונספט ברור של Health-Check, אחרת תנווטו למצבים בלתי יציבים.
• מחרוזת חיבור באמצעות קונפיגורציה/Secret: ניתן לשלוט בזה היטב אם קיימת הפצת קונפיגורציה מרכזית. סיכון: לא כל הרכיבים יאמצו את הקונפיגורציה החדשה בו־זמנית.
• DB-Proxy: יכול לסייע לרכז את ההחלפה, אך מוסיף סיבוכיות נוספת ושירות קריטי חדש בשרשרת.

לתוכנה ארגונית שצמחה עם הזמן לעתים מציאותי שילוב: שירותים מרכזיים עוברים באמצעות קונפיגורציה, „רכיבים ישנים“ דרך DNS. חשוב לתעד ולבדוק זאת ב-Runbook — כולל ה“משרות“ הנשכחות על שרת אפליקציה ישן.

אבטחה ו‑Compliance: השדרוג כהזדמנות, אבל לא כזירת קרב משנית

שדרוגי PostgreSQL הם הזדמנות טובה לסגור חולשות אבטחה: שיטות אימות מיושנות, תפקידים רחבים מדי, שיתופי רשת לא ברורים. במקביל, אסור ש‑Security יהפוך ל‑scope‑creep בלתי מבוקר.

גישה פרגמטית:

• פריטטיות אבטחה ל-Cutover: ה‑Green חייב להיות לפחות מאובטח כמו ה‑Blue, עדיף עם שיפורים קטנים וברורים (למשל ברירות מחדל של TLS, SCRAM במקום MD5, כללי HBA מחמירים יותר).
• מהלכים מבניים גדולים יותר לביצוע לאחר מכן: ריפקטורינג של תפקידים, סגמנטציה מחמירה של הרשת או סיבוב מקיף של Secrets הם מהלכים בעלי ערך, אך עדיף לבצעם כחבילת Change נפרדת לאחר הייצוב.

הערכת מאמץ באופן ריאליסטי: היכן פרויקטים מפסידים זמן בפועל

לתכנון ותקשורת מסייע מבנה מאמץ כנה. לפי הניסיון, זוללי הזמן אינם „להתקין PostgreSQL“, אלא:

• מלאי צרכנים: למצוא את כל הקוראים/הכותבים, להבהיר בעלים, להגדיר את דרך ההחלפה.
• נתוני בדיקה וסביבת בדיקה: נתונים קרובים לייצור (בהתחשב בדרישות הגנת הנתונים) ועומס ריאלי הם קריטיים, אחרת תבדקו לא את הבעיה.
• Runbooks ואישורים: מי רשאי לבצע מה בחלון התחזוקה? מי מחליט על Rollback? מי מתקשר? חוסר בהירות ייצור עיכובים ברגע הקריטי.
• נושאי דרייבר/TLS: אי‑תאמויות קטנות יכולות להוליד תסמינים משמעותיים (התנתקויות ספורדיות, שגיאות אימות, Timeouts).

אם תנהלו נקודות אלה מלכתחילה כחבילות עבודה נפרדות, ה“שדרוג“ יהפוך לפרויקט ניתן לניהול במקום לסוף‑שבוע מלא עצבים.

מסקנה: שדרוג PostgreSQL ללא זמן השבתה הוא בראש ובראשונה עיצוב תפעולי

שדרוג PostgreSQL ללא זמן השבתה לא מושג בעזרת טריק יחיד, אלא באמצעות ארכיטקטורה שמאפשרת החלפה והחזרה באופן מבוקר. Blue/Green מבטיחה את ההפרדה הנדרשת, השכפול מספק את גשר הנתונים, ותוכנית רולבק ריאליסטית מונעת מהצוות, במקרה של שגיאה, להיאלץ לבחור בין אובדן נתונים לבין הפסקת שירות של שעות.

אם תעריכו באופן מסודר את סביבת הצרכנים, תבנו את Green כסביבת תפעול (ניטור, גיבויים, אבטחה), תפקחו על העברת הנתונים ותתאמנו את ה-Cutover כספר ריצה (Runbook) עם קריטריוני ביטול, קפיצת הגרסה תהפוך לשינוי מבוקר – גם בבסיסי נתוני ERP פרודוקטיביים עם ממשקים רבים.

אם ברצונכם להכין את שדרוג מסד הנתונים של ה-ERP באופן מובנה ולהתייחס במשותף לארכיטקטורה, לממשקים ולתוכנית רולבק, דברו איתנו:

לנושא זה גם יש חשיבות ל-Blue/Green Deployment ולתוכנית Cutover. המאמר ממקם היבטים אלה בצורה מובנת ומדגים מה חשוב בעבודה היומיומית.

לדון בפרויקט או במהלך מודרניזציה עם Net-Base.