технологии отработки программ

[Olej]

Я несколько раз примерялся + менял названия темы, чтобы точно в нём обозначить о чём речь:

- вопрос не только программирования, разработки и отладки, но и администрирования, обкатки существующего программного обеспечения и настройки в разных конфигурациях и инсталляциях...

- а вопрос о том: как можно организовать рабочее место, стенд для отработки...

- и собрать для каждого способа организации работы (технологии) все плюсы и минусы, даже те, которые не видимы на первый взгляд.

- + учесть здесь такую не очевидную вещь: процесс отработки ПО (да ещё если с сопровождением и внесением изменений считать) процесс длительный (месяцы и годы), и нужно отслеживать обновления среды исполнения (версии Linux, программные пакеты), т.е. условный стенд должен обновляться на ходу, не теряя адекватности...

- а когда речь идёт о разработке ПО, то здесь тоже принципиально различающихся будет несколько сфер: а). прикладное ПО, мало чувствительное к оборудованию, версиям; б). системное ПО, чувствительное к версиям (партнёров по танцам), но мало зависящее от оборудования; б). модули ядра и драйверы, которые напрямую зависимы от железа.

[Olej]

Этот интерес не с потолка взят, он уже обозначался в другой, соседней здесь теме: viewtopic.php?f=18&t=1618&start=20

И для того, чтобы в программировании модулей делать разработку и использовать API на достаточно свежие версии ядра (поспевать), я знаю только вот такие способы:

1. новые версии ядра выходят в среднем с периодом 12 недель, в итоге, 1-й способ: нужно раз в 1/2 года сносить установленный Linux + ставить свежий дистрибутив; здесь может помочь раздельное размещение /home & /root по разделам HDD.

2. делать обновление версий дистрибутива, так для Fedora где-то здесь обсуждался этот процесс (обновление через 2 версии Fedora: Fedora 12 -> Fedora 14, Fedora 14 -> Fedora 16) ... т.е. "подтягивать" дистрибутив; но этот процесс, к сожалению, временами плохо заканчивается ... иногда он не проходит ОК из-за недостаточного размера /boot, выделенного в отдельном разделе HDD ... при таких сбоях цена вопроса: полностью сносить дистрибутив + п.1 (возврата нет).

3. доставлять (в GRUB) ванильное (официальное) ядро, компилируя из исходников ... в качестве начального приближения взять .config из своего текущего дистрибутива (/boot).

4. (может быть самый умный способ): ставить нужное число виртуальных инсталляций любых ядер/дистрибутивов и запускать их под VirtualBox (а это QEMU); очень хорошо при этом работать с такими VM удалённо, по ssh - или с другого хоста LAN, либо даже с базовой OS ... при этом VM может крытиться без X11.

Больше способов я не знаю.

Но, во-первых, это было очень вскользь и поверхностно, а, во-вторых, нельзя же всё сваливать в одну тему ... на её 6-ти страницах обсуждения...

А тема очень нужная и ... как бы кому не казалось обратное - совсем не такая очевидная.

[Olej]

Но, во-первых, это было очень вскользь и поверхностно,

... кроме того, немного о другом.

А здесь можно чётко выделить (как минимум):

1. технология локальной отработки.
- самая традиционная, сложилась исторически, её 40 лет продвигали все разработчики систем, кто ещё помнит: RSX-11 / RT-11 / LSI-11 (DEC), MS-DOS, Windows ... немного раньше от неё начали отходить IBM/360 ... но этого уже никто не помнит
- самая простая в понимании, на этой технике обучают всех студентов "Hello world!" ... к сожалению, главным здесь, насколько я сталкивался, что спми преподаватели не представляют иной технологии;
- эта техника подталкивает к использованию IDE;

2. технология удалённых рабочих мест.
- здесь очень много вариантов, начиная от самых привычных: сессия telnet, rlogin, ssh ... есть чуть более нетрадиционные вещи, как ssh с тунеллированием X11 протокола + нативное использование X11 протокола на удалённых рабочих станциях...
- но сюда же относится и терминальные подключения в embedded устройствах, в разнообразных kit-ах для отработки, такие подключения привычны через RS-232/RS-485, Ethernet, USB (из свежих примеров: Android SDK + Linux утилита adb в качестве Android-терминала).

3. технология использования виртуальных машин.
- здесь тоже всё понятно, только нужна некоторая привычка: отрабатываем ПО в среде созданной виртуальной машины...
- менеджеры виртуальных машин под Linux могут быть разнообразны ... но для целей отработки ПО наиболее применимые, как мне кажется, QEMU и VirtualBox, которые есть сродственными проектами...

Плюс могут быть какие-то комбинированные варианты:

4. технология использования удалённых виртуальных машин.
- когда под групповую разработку выделяется единый сервер виртуальных машин...
- а работа идёт с удалённых рабочих станций...
- через LAN -> последовательно через виртуальные сетевые интерфейсы -> далее в рабочую виртуальную машину.

Кажется, больше я на практике ничего не встречал + в голову больше ничего не приходит.

[Olej]

И вот теперь к преимуществам и недостаткам... с чего всё и началось:

2. технология удалённых рабочих мест.

Именно в этой технике я бы учил на сегодня (приучал!) студентов и начинающих программистов ... будь на то моя воля.

В явных плюсах:
1. Независимость и от аппаратной и от программной платформы. Хороший пример то как: в OS Solaris на аппаратной платформе SPARK можно программировать с рабочей станции Linux из пользуясь привычной, например, в том же Linux IDE Solaris Studio (в удалённой X11 сессии).
2. На сложном или уникальном оборудовании может работать много разработчиков со своих Linux рабочих станций... очень неплохо для комплексных групповых проектов.
3. Место отрабатываемого стенда может быть удалено на 1000 км. от разработчика ... таким образом можно вести диагностирование, тестирование и доводку удалённых комплексов без необходимости выезда к ним.
4. ... очень любопытно смотрится копи-паст целых фрагментов кода, логов, конфигов ... с сервера А на сервер Б через буфер обмена рабочей станции В - в открытом окне слева А, в открытом окне справа Б ... Элементарно простой способ тиражирования информации по LAN.

Минусов за этой техникой работы я явных и не вижу ... не считая того, что нужно определённый труд и время положить на приобретение привычки к такой работе.
Как ни странно, минусом является субъективная нелюбовь программистов-разработчиков к такой форме организации ... из-за большей подконтрольности состояния дел руководству проекта. Но руководство проекта должно просто сломить такую нелюбовь и возможный саботаж - для целей реализации преимуществ метода.

3. технология использования виртуальных машин.

1. Так же как предыдущий случай - независимость от аппаратных платформ и ОС ... любой каприз.
2. Лёгкость простота и скорость перезагрузки, когда в процессе отработки "положили" систему.
3. Возможность развернуть целую "сетку" виртуальных машин, например, отличающихся ОС, дистрибутивом, версией ядра... - для сравнительной отработки ПО. Это недостижимо практически ни в каких реальных условиях. Совершенно не все виртуальные машины должны быть одновременно активными (запущенными), поэтому такое широкое комплексное тестирование не требует существенного повышения ресурсов.
4. Совершенно уникальная возможность сравнивать результаты выполнения на 1-м, 2-х, 3-х ... процессорах, просто перепределяя настройками в конфигурациях виртуальной машины число процессоров (например на 4-х ядерном хосте можно определить для VM 1,2,3,4 процессора). На реальном оборудовании такое теоретически возможно проделать, но практически недостижимо.
5. Очень часто упускается из виду, что большинство инструментального программного обеспечения на рабочей станции не умеет использовать многопроцессорность (для этого ПО должно быть написано специальным образом, как многопоточное, что чаще всего делается только для серверного ПО массового обслуживания, ... таких как Apache). А нынешние рабочие станции повально многоядерные. Поэтому отработка на VM во многих случаях даже не приведёт к снижению суммарной производительности (работа VM на своих процессорах, работа разработчика - на своих).

Из минусов:
1. После такой отработки всё-равно должен иметь место финальный этап тестирования на реальном железе - могут быть мелкие артефакты.
2. Достаточно хлопотная техника установки и администрирования виртуальных машин, а ещё больше - виртуальных сетей виртуальных машин... но это освваивается один раз, а потом только многократно эксплуатируется.
3. На технически слабых рабочих станциях виртуальные машины могут существенно "жрать" ресурсы ... реально это заметно только по памяти RAM.

4. технология использования удалённых виртуальных машин.

Объединение технологий даёт суммирование достоинств. И нивелирует недостатки.

Кроме того, такой подход позволяет создать и использовать мощный кластер из нескольких виртуальных машин на едином хосте, консолидирующий сетевые сервера и службы, для отработки комплексных сетевых и распределённых проектов (без наличия, собственно, сетевого стенда). Это то, что ещё в Solaris появилось как зоны. Такой единый сетевой стенд должен быть доступен всем удалённым разработчикам, и стать ядром групповой работы. Это сильно большое преимущество.

Я не трогал здесь преимущества-недостатки 1-го, локального способа отработки... но это только потому, что преимущества-недостатки могут быть только относительными, и я выше их предполагал именно относительно локального способа организации работ.

Вот это то, что я могу вспомнить по систематизации преимуществ-недостатков способов организации работ.

Помогайте кто ещё что существенное может добавить.
Что забыл?

[Olej]

3. технология использования виртуальных машин.

1. Так же как предыдущий случай - независимость от аппаратных платформ и ОС ... любой каприз.
2. Лёгкость простота и скорость перезагрузки, когда в процессе отработки "положили" систему.
3. Возможность развернуть целую "сетку" виртуальных машин, например, отличающихся ОС, дистрибутивом, версией ядра... - для сравнительной отработки ПО. Это недостижимо практически ни в каких реальных условиях. Совершенно не все виртуальные машины должны быть одновременно активными (запущенными), поэтому такое широкое комплексное тестирование не требует существенного повышения ресурсов.
4. Совершенно уникальная возможность сравнивать результаты выполнения на 1-м, 2-х, 3-х ... процессорах, просто перепределяя настройками в конфигурациях виртуальной машины число процессоров (например на 4-х ядерном хосте можно определить для VM 1,2,3,4 процессора). На реальном оборудовании такое теоретически возможно проделать, но практически недостижимо.
5. Очень часто упускается из виду, что большинство инструментального программного обеспечения на рабочей станции не умеет использовать многопроцессорность (для этого ПО должно быть написано специальным образом, как многопоточное, что чаще всего делается только для серверного ПО массового обслуживания, ... таких как Apache). А нынешние рабочие станции повально многоядерные. Поэтому отработка на VM во многих случаях даже не приведёт к снижению суммарной производительности (работа VM на своих процессорах, работа разработчика - на своих).

Конечно же:
6. Лёгкость и безбоязненность с которой можно проводить любые операции с виртуальными HDD: изменять размеры, делать переразметку, переносить образы HCC с места на место, создавать их дубликаты для безопасности операций...
viewtopic.php?f=19&t=1625

Конечно, можно и на реальном HDD ... менять размеры и расположения разделов:
- gparted ... когда известен тип fs;
- LVM ... но с хлопотами;
- что-то типа файловой системы zfs Open Solaris.
Но это всё очень рисково на реале: на грани фола

[Olej]

4. технология использования удалённых виртуальных машин.
- когда под групповую разработку выделяется единый сервер виртуальных машин...
- а работа идёт с удалённых рабочих станций...
- через LAN -> последовательно через виртуальные сетевые интерфейсы -> далее в рабочую виртуальную машину.

Вопрос стоит того, чтобы к нему вернуться.
Отрабатывал сетевые драйверы (модули ядра), здесь в соседней теме: viewtopic.php?f=18&t=1646&start=0
Дело это такое, что при этом завалить Linux - дело плёвое, умирает мгновенно, даже не успевая сообщение Ooops из ядра на терминал выбросить.

Естественное решение - отрабатывать на VM, доступаясь к этой VM по сети.
Но неприятность в том, что работу то мы ведём с сетевым адаптером этой VM, и как только с ним что-то намудрили - это "по сети" отваливается, VM становится совершенно автономной и беспомощной, и её нужно идти и руками перегружать... Опять та же история.

И постепенно сложился крайне удобный стенд для отработки ... вообще всяких сетевых приложений.
Я думаю, что его нужно рассказать:

- рабочая станция с которой я делаю всю редактуру - 192.168.1.5 (имя хоста notebook) ...
- главный хост для отработки 192.168.1.5 (имя хоста nvidia), на этом хосте и выполняется VirtualBox ...
- это адреса - в реальной LAN
- в VirtualBox крутится испытуемая, отлаживаемая VM - (имя хоста fedora16vm)
- на этом хосте создаём виртуальный сетевой адаптер, вот в таком режиме:

- тогда этот интерфейс получит IP из реальной LAN: 192.168.1.20
- но чтобы не валить связь при ошибках, отработку будем делать совсем для другого созданного сетевого адаптера, и совсем в другом режиме:

- это уже совершенно другая подсетка 192.168.56.х, хост nvidia в ней получает в ней IP=192.168.56.1, а fedora16vm IP=192.168.56.101
(естественно, все адреса произвольные, и рисую я их только для определённости)

Всё, получился замечательный стенд, который не заваливается ни при каких ошибках отработки:
1. из notebook я по SSH соединён через 192.168.1.20 с fedora16vm ... редактура кода, компиляция, запуск ... оттуда забираю результаты и пром. варианты в архив - эта связь никогда не рвётся;
2. из notebook я по SSH соединён через 192.168.1.5 с nvidia - это хост для отладки сетевых обменов, оттуда я подаю команды трафика на отлаживаемый хост fedora16vm - эта связь тоже никогда не рвётся;
3. IP=192.168.56.1 (nvidia) и IP=192.168.56.101 (fedora16vm) - это отлаживаемый конект - это может обрываться сколько влезет, я всегда зайду по п.1 и всё поправлю.

Вот такой незаваливаемый и очень универсальный стенд.