הסמכת אפליקציה לחנות האפליקציות של Bitrix24

מדוע הסמכת Bitrix24 מתעכבת ומה נשבר

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

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

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

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

אנחנו מפרקים כיצד לסגור את הסיבות הללו לפני השליחה לבדיקה.

מה נותנת אפליקציה מוסמכת: מהירות וסירובים

לוחות זמנים לפרסום: מהבנייה ועד הוויטרינה

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

מספר הגרסאות הנדחות יורד פי כמה

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

קבוצת כשלים בהתקנה נעלמת

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

התמיכה מתפנה מפניות טיפוסיות

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

דרכים לעבור הסמכת Bitrix24: מה לבחור

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

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

שלבי ההסמכה: מביקורת קוד ועד לפרסום

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

1. ביקורת קוד האפליקציה — ניתוח סטטי ובדיקה ידנית של מטפלי אירועים, פניות לשירותים חיצוניים, עבודה עם מטמון ותורים. מחפשים קריאות חוסמות בתרחישי משתמש ומקומות שבהם שגיאה של שירות חיצוני שוברת את הממשק.
2. סכמת אינטגרציות — מפת קריאות חיצוניות עם נקודות כשל: פסקי זמן, ניסיונות חוזרים, התנהגות כששירות צד שלישי לא זמין, נפח הנתונים המועברים בסשן אחד.
3. הגדרת סביבה — קונטור מבודד עם פורטל ונתונים נפרדים, מפתחות גישה, מטפלי התקנה ומחיקה, כך שהאפליקציה תותקן על מערכת נקייה בלי פעולות ידניות של מנהל.
4. תיקוני הרשאות גישה — מצמצמים את ההרשאות המבוקשות למינימום ההכרחי לתרחיש המוצהר: תחומי גישה מיותרים מאטים את הבדיקה ומרתיעים את מי שמתקין את האפליקציה.
5. קונטור בדיקות של המרקטפלייס — הרצה על כמה מהדורות ותעריפים, תרחישי הפעלה ראשונה, שדרוג מהגרסה הקודמת ומחיקה מלאה.
6. בדיקה לפי צ'קליסט הפרסום — התקנה חוזרת, מיגרציות תקינות, תיעוד שגיאות ביומן, היענות הממשק, טקסטים ותיאורים של כרטיס האפליקציה.
7. מסירה וליווי — הוצאת עדכונים, ניתוח הערות של בודקים, מענה לפניות משתמשים לאחר הפרסום.

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

ארטיפקטים ומסמכים שנשארים אצל הלקוח

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

• תיעוד האפליקציה — אילו תרחישים היא סוגרת, אילו ישויות בפורטל היא קוראת ואילו משנה, ממה מורכב הממשק ומה קורה כאשר שירות חיצוני נכשל.
• סכמת אינטגרציות — כיווני הקריאות, מערכות חיצוניות, נקודות כשל והתנהגות כאשר כל אחת מהן לא זמינה.
• מדיניות גישה — תפקידים, תחומי הרשאות, הפרדה בין הרשאות קריאה וכתיבה, סדר אחסון והחלפה של מפתחות גישה.
• תצורות סביבות — רשימת פרמטרים של קונטור העבודה והבדיקות, מה הוצא למשתנים, ומה אסור לשנות בלי בדיקה חוזרת.
• נוהל התקנה ועדכון — סדר שלב-אחר-שלב לפרסום גרסה, מיגרציות נתונים, תנאים וגבולות של חזרה לגרסה הקודמת.
• נוהל ליווי — זמני תגובה לפניות, חלונות עבודה מתוכננים, מי ומאילו אירועים מקבל התראות.
• צ'קליסט לפני פרסום — בדיקות הרשאות, טיפול בשגיאות, הרצת תרחישים בקונטור בדיקות, מוכנות תיאור הגרסה החדשה.
• יומן שינויים ופניות — מה ומתי השתנה, אילו הערות של בודקים כבר נסגרו, כדי לא לחזור על הניתוח מחדש.

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

מקרה בוחן: כיצד האפליקציה עברה בדיקה בניסיון השני

מה היה לפני הבדיקה

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

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

תיקון ההערות ובדיקה חוזרת

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

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

מדדים לפני ואחרי: שיעור תרחישי ההתקנה המכוסים בבדיקות אוטומטיות עלה מ-40 ל-90%, הערות על הרשאות גישה בבדיקה החוזרת — אפס, התקנה על פורטל מוכן מסתיימת בדקה במקום נפילה עם שגיאה. פניות לתמיכה בנושא התקנה לאחר הפרסום פסקו — תקלות טיפוסיות נסגרו ברמת הקוד, ולא בהוראה למנהל.

במה דרישות המרקטפלייס שונות מבדיקת קוד פנימית?

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

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

סגנון הקוד ובחירת הספריות לא מעניינים את הבודק — חשוב מה האפליקציה עושה עם נתוני הלקוח ועם הפורטל עצמו.

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

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

בדיקות, תיעוד ביומן ופרטיות נתונים: נקודות שנויות במחלוקת

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

מי מבפנים רואה את נתוני המשתמשים?

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

מה עושים עם תלויות חיצוניות?

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

איך לעדכן אפליקציה שכבר פורסמה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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