У владі скриптів, Відкриті системи
Процедури управління життєвим циклом додатків, які використовуються у спільноті Open Source, відрізняються від прийнятих у постачальників комерційних продуктів, що можна проілюструвати на прикладі досвіду української компанії ALT Linux.
Компанія ALT Linux прагне створення моделі розробки, яка вже досить давно існує вDebian. Ця група об'єднує понад 300 фахівців з усього світу, які займаються підтримкою та розвитком понад десять тисяч пакетів. Особливість ситуації в тому, що в Debian немає комерційної частини спільноти, а є лише незалежні розробники та набір центральних серверів, на якому працюють скрипти автоматизованої підготовки пакетів. На цих серверах розташовується кілька репозиторіїв: стабільні та перебувають у розробці. Репозиторії виходять для шести платформ і є фонд, який займається матеріальним забезпеченням техніки центральних серверів. Багатоплатформність Debian, що реалізується також за допомогою спеціального скрипта autobuilders, який розпаковує пакет із вихідними текстами програми та компілює її під конкретне апаратно-програмне середовище. Тільки після того, як програма була коректно скомпільована на всіх платформах, вона потрапляє в нестабільний репозиторій Debian. Потім користувачі та інші розробники тестують програму пакета і повідомляють про знайдені помилки, виставляючи їм певний рівень. Щоб додаток потрапив у стабільний дистрибутив, розробник повинен вирішити всі помилки, помічені як блокуючі випуск (release critical). Дистрибутив оголошується стабільним, коли всі його пакети пройшли цю процедуру.
У спільноті розробників Debian є виборні посади, такі як президент або менеджер з випуску дистрибутива, які маютьлише номінальну влада — правила розробки описані настільки точно, що з'явилася можливість реалізувати їх у вигляді скриптів, які керують процесом без участі людини. Звичайно, «стрічку перерізає» менеджер із випуску, але він не має права випустити продукт із невирішеними проблемами або закрити їх самостійно. ALT Linux вибудовує аналогічну систему, де немає суб'єктивізму, а є суворі правила, виражені в скриптах.
У світі Unix явно простежуються два підходи до розробки, що відображають відповідно точки зору програміста і системного адміністратора. Програміст робить продукт, який, будучи написаним правильно, має працювати скрізь. Завдання системного адміністратора - забезпечити роботу на конкретній платформі та в конкретних умовах. Якщо адміністратор намагається знайти загальне рішення на всі випадки життя, це говорить про його некомпетентність. Якщо ж розробник намагається побудувати приватне рішення, засноване на певних хитрощах і працюватиме лише за певних умов, його не можна назвати хорошим програмістом.
Репозиторій
Вся розробка програмного забезпечення в ALT Linux пов'язана із загальним репозиторієм Sisyphus, в який потрапляють нові версії програм, у тому числі і неперевірені. Тут зберігаються відкомпільовані програми, вихідні тексти та файли документації, щоправда, не у форматі .deb, як це заведено в Debian, а у вигляді RPM-пакетів. Перш ніж якийсь пакет буде перенесено до стабільної частини репозиторію, він спочатку потрапляє до Sisyphus, звідки його беруть на тестування зацікавлені користувачі. Щоб пакет потрапив у Sisyphus потрібно, щоб знайшлася людина, яка б погодилася його супроводжувати. Їм може стати будь-хто, хто продемонструє своє вміння компілювати програми та збирати RPM-пакети. Пакети в ALT Linux збираються за особливими вимогами, зокрема, у пакетах має бути документація, а файл Changelog, який містить інформацію про внесені в пакет зміни, не повинен бути порожнім. Скрипти, що заповнюють репозиторій, виконують необхідні перевірки та не викладають нові компоненти у загальний доступ, доки не будуть задоволені всі правила.
Є ще одне незаперечне правило — відкомпільовані програми не можуть потрапити до репозиторію без пакета вихідних текстів. Це з тим, що за правилами ALT Linux залежності в RPM-пакетах генеруються скриптами автоматично з поведінки компонувальника. Справа в тому, що утиліта apt-get не може бути застосована до довільного набору пакетів, оскільки це може зруйнувати систему, що вже працює. Хоча в RPM і передбачені механізми управління взаємозв'язками, вони повністю залежать від свавілля того, хто збирає пакет, тому довелося розробити жорсткі вимоги саме до процесу збирання; точне дотримання залежностей гарантує правильну роботу встановлених за допомогою програм apt-get.
Sisyphus призначений для розробників і ніколи не стає стабільним. Тим не менш, користувачі можуть оновлювати свої програми з нього, але рекомендується зробити спочатку пробне оновлення, і тільки якщо воно повністю протестоване, переносити його на робочі машини. Таким чином, основний продукт ALT Linux Team це репозиторій Sisyphus, а вже компанія ALT Linux розробляє на його основі свої стабільні дистрибутиви: Master, Junior, Castle та ін.
Репозиторії, що містять велику кількість пакетів, повинні відповідати вимогам узгодженості - у всіх пакетах повинні бути правильно встановлені всі необхідні залежності виконання і усунуті зайві зв'язки. Для кожного пакета повиннібути визначені інші пакети, без яких даний не працюватиме. У системах з великою кількістю пакетів важливо не тільки встановити залежності виконання у кожному конкретному пакеті, але мати узгоджену систему залежностей у всіх пакетах репозиторію з урахуванням версій. У кожному новому пакеті потрібно вказувати поточні версії, щоб програма оновлення своєчасно модифікувала базові бібліотеки. А якщо ні, то займатися оновленнями ризиковано, оскільки система може перестати працювати вже після чергового оновлення.
Більш інтелектуальні програми можуть обчислювати пакети, необхідні самостійного складання програми. В ALT Linux використовуються саме такі скрипти складання (це потрібно, наприклад, при складанні пакетів у локальному chroot-оточенні або під іншу платформу). Залежності зі складання дозволяють створювати окреме середовище для складання програми, що гарантує працездатність програми практично в будь-якому середовищі, в якому дотримані зазначені залежності. Дотримання залежностей зі складання гарантує, що в системі встановлені всі компоненти, необхідні для компіляції пакета.
Sisyphus побудований так, щоб будь-яка інша компанія могла на його основі випустити свій спеціалізований дистрибутив. Sisyphus - не просто репозиторій пакетів, а набір рішень, як будь-який універсальний дистрибутив Linux. У ньому реалізовано велику кількість ідей у сфері безпеки, інтернаціоналізації та управління пакетами. Більшість серверних програм були спеціально переписані для роботи в chroot-оточенні, що підвищило стійкість системи по відношенню до атак на окремі мережеві служби. Крім того, було переписано систему реєстрації користувачів, яка спрощує контроль. Знайдені помилки в системі друку, які виникли через неправильнулокалізації. Також перекладено українською мовою інтерфейси комунікатора Mozilla, пакету офісних програм OpenOffice.org, підготовлено набір шаблонів документів, максимально наближених до вітчизняних реалій.
Щоправда, щоб цей набір перетворився на закінчений продукт, потрібна повноцінна документація. Ідеальним рішенням була б система, за допомогою якої користувач міг виділити підмножину необхідних пакетів, а вона вже самостійно укомплектувала цей набір всім необхідним для роботи і установки.
Спілкування в Open Sourсe
Важливе місце у процесі розробки займають списки розсилки, які, по суті, склеюють співтовариство розробників, що дозволяє взаємодіяти великій територіально розподіленій команді. В ALT Linux намагаються підтримувати конструктивний дух у списках розсилки для розробників, який би дозволив вирішувати проблеми, а не займатися словесними баталіями. Списки не модеруються, але за їхню роботу відповідають певні люди, які можуть «відписати» когось від списку, але не вправі видаляти з листування або архівів жодного повідомлення.
Рівень помилки визначає той, хто її помітив. Самі розробники визначають до третини помилок, які потрапляють до BTS, і не мають права приховувати інформацію про них. Якщо помилку було допущено в сторонній системі, то її рішення може перейти до іншого розробника. Власне, процес усунення помилки не однозначний, оскільки вона може виявлятися в сторонніх додатках, а розташовуватися в базовій бібліотеці. Тим не менш, спільнота розробників не відповідає за випуск нових продуктів: цим займається менеджер випуску, який перевіряє правильність складання та працездатність програмного забезпечення.
Підтримка від Open Sourсe
ALT Linux взяла дуже багато від Debian, взокрема утиліту онлайнового оновлення apt-get, що є компонентом репозитарію Sisyphus. Щоправда, у Debian використовується свій власний формат пакетів .deb, а Sisyphus побудований більш відомому форматі RPM. Тому apt-get був узятий не від Debian, а адаптований під RPM бразильською компанією Connectiva, яка займається випуском своїх дистрибутивів Linux. Використання apt-get дозволяє встановити або оновити будь-який заздалегідь визначений набір програмного забезпечення за допомогою єдиної команди. При цьому оновиться не лише необхідний користувачеві компонент, а й інші пакети, від яких залежить.
Утиліта apt-get взаємодіє з репозиторіями, наприклад Sisyphus, звіряючи версії пакетів і завантажуючи оновлені. ALT Linux підтримує кілька різних репозиторіїв. Стабільними наборами пакетів є ті, які жорстко прив'язані до випущених дистрибутивів. Оновлення стабільних дистрибутивів відбувається вкрай рідко - в основному при виправленні помилок, що стосуються безпеки.
Деякі компанії встановлюють у себе «дзеркало» репозиторію та оновлюють усі комп'ютери по локальній мережі. У цьому адміністратори локальних репозиторіїв можуть оновлювати не весь набір додатків, лише найнеобхідніше чи перевірене. З цього репозиторію можна друкувати спеціальні компакт-диски та розсилати їх на філії для оновлення. Причому дистрибутив є утиліти для автоматизації цього процесу. Якщо ж цього мало, то компанія може замовити у ALT Linux додаткову стабілізацію певних додатків. Вся технічна підтримка здійснюється стандартними шляхами через списки розсилки та систему онлайнових оновлень.
Розробники
Навіщо ж розробники програм співпрацюють із ALT Linux, розкриваючи вихідні текстисвоїх рішень? Справа в тому, що творцям системи для ALT Linux Team самим потрібна базова платформа, яка б відповідала їх вимогам. Причому бажано контактувати з тими людьми, які беруть участь у розробці цих компонентів. Звичайно, розробники припускають, що їхні рішення також комусь можуть знадобитися. В результаті виникає співтовариство творців програмного забезпечення. Беручи участь у ньому, кожен отримує саме те, що йому потрібно, але також відкриває іншим свої розробки.
Якщо йдеться про матеріальну зацікавленість, то ALT Linux залучає для своїх проектів людей із команди розробників для виконання певних замовлень. Втім, розробники із спільноти можуть заробляти і «на стороні», де вони працюють із певними системами та хочуть мати вплив на їх подальший розвиток. Вони лише збирають пакети та викладають їх у репозиторій, але натомість отримують набагато більше — інтегрованість пакетів та їхню узгодженість, а також можливість обговорити проблеми з розробниками пакету та домовитися з ними про нові функції чи вирішення конкретних проблем. Одночасно у розробників, що виконують правила складання пакетів для Sisyphus, з'являється можливість поширювати свої продукти не як окремий додаток, а у складі готової, узгодженої та інтегрованої системи, розвиваючи тільки ту функціональність, яка є родзинкою його застосування.
Валерій Коржов([email protected]) - оглядач, Computerword Україна, (Москва). Автор вдячний Олексію Новодворському, технічному директору компанії ALT Linux, за допомогу у підготовці статті.
Прикладом служби технічної підтримки є ситуація з бібліотекою zlib, яка займається архівуванням файлів у форматі zip. Убібліотеці було знайдено помилку, що дозволяє скласти такий архів, розпакування якого могло б зашкодити системі. Ця помилка була присутня практично для всіх платформ. Сама бібліотека була настільки маленька, що розробники додатків воліли інтегрувати її в додаток (статична компоновка), а не користуватися бібліотекою, що розділяється, тобто динамічно підвантажується. Як тільки помилка була помічена, розробники ALT Linux поступово почали переходити до динамічного компонування. Коли ж помилку було визнано офіційно, вже за чотири хвилини в Sisyphus було вміщено нову виправлену версію бібліотеки. Якщо користувач оновлював свою систему, помилки прибиралася з неї автоматично. Таким чином, користувач отримував технічну підтримку непомітно йому самого. У системах із закритими вихідними текстами ця помилка може зберігатися й досі.
Поділіться матеріалом з колегами та друзями