Что такое окружение в it

В приведенном примере мы осуществили простой синтаксический анализ массива environ, так как переменные и значения представлены в нем в обычном виде (ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ). К счастью нам больше не придется осуществлять синтаксический разбор массива environ. О настоящем предназначении этого массива будет рассказано в главе, посвященной многозадачности.

4.3. Чтение окружения: getenv()

В заголовочном файле stdlib.h объявлена функция getenv , которая доказывает, что в предыдущем примере мы изобрели велосипед. Ниже приведен адаптированный прототип этой функции.

 char * getenv (const char * name);  

Функция эта работает очень просто: если в качестве аргумента указано имя существующей переменной окружения, то функция возвращает указатель на строку, содержащую значение этой переменной; если переменная отсутствует, возвращается NULL.

Как видим, функция getenv() позволяет не осуществлять синтаксический разбор environ. Напишем новую программу, которая делает то же, что и предыдущая, только более простым способом. Назовем ее getenv по имени функции — виновника торжества.

 /* getenv.c */ #include #include int main (int argc, char ** argv) < if (argc < 2) < fprintf (stderr, "getenv: Too few arguments\n"); fprintf (stderr, "Usage: getenv \n"); exit (1); > char * var = getenv (argv[1]); if (var == NULL) < printf ("'%s' not found\n", argv[1]); exit (0); >printf ("'%s=%s' found\n", argv[1], var); exit (0); >  

4.4. Запись окружения: setenv()

Пришла пора модифицировать окружение! Еще раз напоминаю: каждый процесс получает не доступ к окружению, а копию окружения родительского процесса (в нашем случае это командная оболочка). Чтобы добавить в окружение новую переменную или изменить существующую, используется функция setenv, объявленная в файле stdlib.h. Ниже приведен адаптированный прототип этой функции.

 int setenv (const char * name, const char * value, int overwrite);  

Если хотите узнать, что значит «адаптированный прототип», загляните в /usr/include/stdlib.h на объявления функций getenv() и setenv() и больше не спрашивайте 😉

Функция setenv() устанавливает значение (второй аргумент, value) для переменной окружения (первый аргумент, name). Третий аргумент — это флаг перезаписи. При ненулевом флаге уже существующая переменная перезаписывается, при нулевом флаге переменная, если уже существует, — не перезаписывается. В случае успешного завершения setenv() возвращает нуль (даже если существующая переменная не перезаписалась при overwrite==0). Если в окружении нет места для новой переменной, то setenv() возвращает -1.

Наша новая программа setenv читает из командной строки два аргумента: имя переменной и значение этой переменной. Если переменная не может быть установлена, выводится ошибка, если ошибки не произошло, выводится результат в формате ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ. Вот эта программа:

 /* setenv.c */ #include #include #define FL_OVWR 0 /* Overwrite flag. You may change it. */ int main (int argc, char ** argv) < if (argc < 3) < fprintf (stderr, "setenv: Too few arguments\n"); fprintf (stderr, "Usage: setenv \n"); exit (1); > if (setenv (argv[1], argv[2], FL_OVWR) != 0) < fprintf (stderr, "setenv: Cannot set '%s'\n", argv[1]); exit (1); >printf ("%s=%s\n", argv[1], getenv (argv[1])); exit (0); >  

Изменяя константу FL_OVWR можно несколько изменить поведение программы по отношению к существующим переменным окружения. Еще раз напоминаю: у каждого процесса своя копия окружения, которая уничтожается при завершении процесса. Экспериментируйте!

4.5. Сырая модификация окружения: putenv()

Функция putenv(), объявленная в заголовочном файле stdlib.h вызывается с единственным аргументом — строкой формата ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ или просто ПЕРЕМЕННАЯ. Обычно такие преформатированные строки называют запросами. Если переменная отсутствует, то в окружение добавляется новая запись. Если переменная уже существует, то текущее значение перезаписывается. Если в качестве аргумента фигурирует просто имя переменной, то переменная удаляется из окружения. В случае удачного завершения, putenv() возвращает нуль и -1 — в случае ошибки.

У функции putenv() есть одна особенность: указатель на строку, переданный в качестве аргумента, становится частью окружения. Если в дальнейшем строка будет изменена, будет изменено и окружение. Это очень важный момент, о котором не следует забывать. Ниже приведен адаптированный прототип функции putenv:

 int putenv (char * str);  

Теперь напишем программу, использующую putenv(). Вот она:

 /* putenv.c */ #include #include #include #define QUERY_MAX_SIZE 32 char * query_str; void print_evar (const char * var) < char * tmp = getenv (var); if (tmp == NULL) < printf ("%s is not set\n", var); return; >printf ("%s=%s\n", var, tmp); > int main (void) 

Программа немного сложнее тех, что приводились ранее, поэтому разберем все по порядку. Сначала создаем для удобства функцию print_evar (PRINT Environment VARiable), которая будет отражать текущее состояние переменной окружения, переданной в качестве аргумента. В функции main() перво-наперво выделяем в куче (heap) память для буфера, в который будут помещаться запросы; заносим адрес буфера в query_str. Теперь формируем строку, и посылаем запрос в функцию putenv(). Здесь нет ничего необычного. Дальше идет демонстрация того, на чем я акцентировал внимание: простое изменение содержимого памяти по адресу, хранящемуся в query_str приводит к изменению окружения; это видно из вывода функции print_evar(). Наконец, вызываем putenv() со строкой, не содержащей символа ‘=’ (равно). Это запрос на удаление переменной из окружения. Функция print_evar() подтверждает это.

Хочу заметить, что putenv() поддерживается не всеми версиями Unix. Если нет крайней необходимости, лучше использовать setenv() для пополнения/модификации окружения.

4.6. Удаление переменной окружения: unsetenv()

Функция unsetenv(), объявленная в stdlib.h, удаляет переменную из окружения. Ниже приведен адаптированный прототип этой функции.

 int unsetenv (const char * name);  

Прежде всего хочу обратить внимание на то, что раньше функция unsetenv() ничего не возращала (void). С выходом версии 2.2.2 библиотеки glibc (январь 2001 года) функция стала возвращать int.

Функция unsetenv() использует в качестве аргумента имя переменной окружения. Возвращаемое значение — нуль при удачном завершении и -1 в случае ошибки. Рассмотрим простую программу, которая удаляет переменную окружения USER (. ). Для тех, кто испугался, напоминаю еще один раз: каждый процесс работает с собственной копией окружения, никак не связанной с копиями окружения других процессов, за исключением дочерних процессов, которых у нас нет. Ниже приведен исходный код программы, учитывающий исторические изменения прототипа функции unsetenv().

 /* unsetenv.c */ #include #include #include #include #define OLD_LIBC_VERSION 0 #define NEW_LIBC_VERSION 1 #define E_VAR "USER" int libc_cur_version (void) < int ret = strcmp (gnu_get_libc_version (), "2.2.2"); if (ret < 0) return OLD_LIBC_VERSION; return NEW_LIBC_VERSION; >int main (void) < int ret; char * str; if (libc_cur_version () == OLD_LIBC_VERSION) < unsetenv (E_VAR); >else < ret = unsetenv (E_VAR); if (ret != 0) < fprintf (stderr, "Cannot unset '%s'\n", E_VAR); exit (1); >> str = getenv (E_VAR); if (str == NULL) < printf ("'%s' has removed from environment\n", E_VAR); >else < printf ("'%s' hasn't removed\n", E_VAR); >exit (0); >  

В программе показан один из самых варварских способов подстроить код под версию библиотеки. Это сделано исключительно для демонстрации двух вариантов unsetenv(). Никогда не делайте так в реальных программах. Намного проще и дешевле (в плане времени), не получая ничего от unsetenv() проверить факт удаления переменной при помощи getenv().

4.7. Очистка окружения: clearenv()

Функция clearenv(), объявленная в заголовочном файле stdlib.h, используется крайне редко для полной очистки окружения. clearenv() поддерживается не всеми версиями Unix. Ниже приведен ее прототип.

 int clearenv (void);  

При успешном завершении clearenv() возвращает нуль. В случае ошибки возвращается ненулевое значение.

В большинстве случаев вместо clearenv() можно использовать следующую инструкцию:

 environ = NULL;  

Окружения развёртывания программного обеспечения

Только что опубликовал в русской википедии перевод статьи Deployment environment.

Публикую этот перевод здесь также. Замечания и комментарии приветствуются.

В развёртывании программного обеспечения, окружение или ярус является компьютерной системой в которой компьютерная программа или компонент программного обеспечения развёртывается и выполняется. В простом случае, такое развёртывание и немедленное выполнение программы на той же машине, может выполнятся в единственном окружении, однако при промышленной разработке используется разделение на development окружение (‘окружение разрабочика’) (где делаются исходные изменения) и production окружение (которое используют конечные пользователи); часто с промежуточными этапами (‘stages’) посередине. Этот структурированный процесс управления релизами может иметь фазы deployment (rollout, ‘развёртывание’, ‘выкатка’), testing (‘тестирование’), и rollback (‘откат’) в случае проблем.

Окружения могут существенно отличаться в размерах: deployment окружение это обычно рабочая станция отдельного разработчика, в то время как production окружение может быть сетью множества географически разнесённых машин в случае с дата-центров, или виртуальными машинами в случае с облачными решениями. Код, данные и конфигурация могут быть развёрнуты паралельно, и нет необходимости связи с соответствующим ярусом — например, pre-production код может подсоединяться к production БД.

Архитектуры

Архитектуры развёртывания существенно разнятся, но в целом, ярусы начинаются с develpment (DEV) и заканчиваются production (PROD). Распространённой 4-х ярусной архитектурой является каскад ярусов deployment, testing, model, production (DEV, TEST, MODL, PROD) c деплоем софта на каждом ярусе по очереди. Другое распространённое окружение это Quality Control (QC), для приёмочного тестирования; песочница или экспериментальное окружение (EXP), для экспериментов не предназначенных для передачи в продакшен; и Disaster Recovery (‘аварийное восстановление’), для предоставления возможности немедленного отката в случае проблемы с продакшеном. Другой распространённой архитектурой является deployment, testing, acceptance and production (DTAP).

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

Точные определения и границы между окружениями варьируется — test может рассматриваться как часть dev, приёмка может рассматриваться как часть test, часть stage, или быть отдельной и так далее. Основные ярусы обрабатываются в определённом порядке, с новыми релизами при развёртывании (rolled out или pushed) на каждом. Ярусы experimental и recovery, если представлены, являются внешними к этому процессу — experimental релизы являются конечными, в то время как recovery являются обычно старыми или дублирующими версиями production, развёрнутыми после production. В случае проблем, в последнем случае можно сделать roll back к старому релизу, и большинство просто выкатывают старый релиз таким же способом как новый. Последний шаг, деплой в production («pushing to prod») самый чувствительный, т.к. здесь любые проблемы напрямую влияют на пользователя. По этой причине это часто управляется по разному, но как минимум мониторится более тщательно, и в некоторых случаях имеется фаза отката или простого переключения. Лучше всего избегать названия вроде Quality Assurance (QA); QA не означает тестирование софта. Тестирование важно, но это отличается от QA.

Иногда развёртывание выполняется вне обычного процесса, главным образом для предоставления срочных или небольших изменений, без необходимости полного релиза. Это может быть один патч, большой service pack или небольшой hotfix.

Окружения могут быть очень разных размеров: разработка обычно идёт на индивидуальных машинах разработчиков (хотя это могут быть тысячи разработчиков), в то время как продакшеном могут быть тысячи географически распределённых машин; тестирование и QC может быть маленьгим и большим, зависеть от предоставленных ресурсов, а staging может варьироваться от единичной машины (подобно canary) до точных дубликатов продакшена.

Окружения

Local

Development/Thunk

Сервер разработки выступающий как песочница где разработчик может выполнить unit-тестирование

Integration

Основа для построения CI, или для тестирования сайд-эффектов разработчиком

Testing/Test/QC/Internal Acceptance

Окружение в котором выполняется тестирование интерфейса. Команда контроля качества проверяет что новый код не будет иметь влияния на существующую функциональность системы после деплоя нового кода в тестовое окружение.

Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo

Production/Live

Серверы конечных пользователей/клиентов

Окружение разработчика

Окружение разработчика (dev) является окружением в котором софт разрабатывается, это часто просто компьютер разработчика. Это отличается от конечной целевой среды некоторыми вещами — цель может не быть стационарным компьютером (это может быть смартфон, встроенная система, самоуправляемый транспорт датацентра и т.д.), и даже если это стационарный компьютер, окружение разработчика будет включать инструменты разработчика например компилятор, IDE, различные или дополнительные версии библиотек и вспомогательного софта, и т.д., что не представлено в пользовательском окружении.

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

Тестовое окружение

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

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

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

Staging

Stage или stage-окружение — это среда для тестирования, которая в точности похожа на продакшен-окружение. Она стремится как можно точнее отразить реальное продакшен-окружение и может подключаться к другим продакшен-сервисам и данным, таким как базы данных. Например, серверы будут работать на удаленных машинах, а не локально (как на рабочей станции разработчика во время разработки, или на одной тестовой машине во время тестирования), чтобы проверить влияние сети на систему.

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

Другим важным использованием stage-окружения является тестирование производительности, в частности нагрузочное тестирование, так как это часто чувствительно для окружения.

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

Продакшен-окружение

Продакшен-окружение также известно как live (в частности в применении к серверам) так как это окружение, с которым непосредственно взаимодействуют пользователи.

Развертывание в производственной среде является наиболее чувствительным шагом; это может осуществляться путем непосредственного развертывания нового кода (перезаписывания старого кода, так что только одна копия представлена в один момент времени), или путем развертывания изменения конфигурации. Это может принимать различные формы: параллельное развертывание новой версии кода и переключение на неё с изменением конфигурации; развертывание новой версии кода рядом со старым с соответствующим «флагом нового функционала», и последующее переключение на новую версию с изменением конфигурации, которая выполнит переключение этого «флага»; или развертывание отдельных серверов (один выполняет старый код, другой — новый) с перенаправлением трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Всё это, в свою очередь, может быть применено одновременно или выборочно, и на разных этапах.

Развертывание новой версии обычно требует перезапуска, если только нет возможности горячего переключения, и поэтому требует либо прерывания обслуживания (обычно это пользовательское ПО, когда приложения должны быть перезагружены), либо дублирования — постепенного перезапуска экземпляров «за спиной» у балансировщика нагрузки, либо заблаговременного запуска новых серверов с последующим простым перенаправлением трафика на новые сервера.

При выкатке нового релиза в продакшен, вместо немедленного развертывания для всех экземпляров или пользователей, его можно сначала развернуть на одном экземпляре или для части пользователей, а затем уже либо развернуть для всех экземпляров, либо поэтапно по фазам, чтобы оперативно отлавливать возникающие проблемы. Это похоже на staging, за исключением того, что делается в продакшене, и по аналогии с добычей угля называется canary release. Это добавляет сложности если несколько релизов запускаются одновременно, и, поэтому их обычно стараются делать быстро, чтобы избежать проблем совместимости.

Применение во фреймворках

Develpment, Staging и Production являются известными и документированными переменными окружения в ASP.NET Core. В зависимости от указанной переменной, выполняется разный код и разный рендеринг контента, применяются разные настройки безопасности и отладки.

См. также

• Управление жизненным циклом приложения
• Deployment, testing, acceptance and production (DTAP)
• IDE
• Разработка ПО

Что такое окружение в it

Окружение проекта (Project environment) – это среда проекта, порождающая совокупность внутренних и внешних сил, которые способствуют или мешают достижению целей проекта [1].

Разработка и оценка проекта, его начало, и реализация осуществляется в соответствующем контексте или среде, которая оказывает на него прямое или косвенное влияние. Каждое из этих воздействий, обусловленных стандартами, возникающими проблемами, существующими тенденциями и т.д. имеет отношение к тому, как проект задумывается и разрабатывается. Общая схема окружения проекта приведена на рисунке 3.4 [6].

Рисунок 3.4 – Общая схема воздействия факторов на проект

Можно условно выделить внешнюю и внутреннюю среду проекта (рисунок 3.5).

Рисунок 3.5 – Схема окружения проекта

Примерами внешнего окружения (internal influences) проекта могут быть геофизические, экологические, социальные, психологические, культурные, политические, экономические, финансовые, юридические, организационные, технологические и эстетические аспекты. Кроме того, во внешней среде можно выделить: ближнее окружение – это среда предприятия, в рамках которого осуществляется проект, и дальнее окружение, т.е. окружение самого предприятия (рисунок 3.6) [1-6].

Рисунок 3.6 – Окружение проекта в составе предприятия

Наиболее существенные факторы внутренней среды следующие:

• стиль руководства проектом;
• специфическая организация проекта;
• участники проекта;
• команда проекта;
• экономические, социальные, технические и др. условия проекта.

Среди факторов ближнего окружения проекта можно выделить следующие:

• руководство предприятия;
• сфера финансов;
• сфера сбыта;
• сфера материального обеспечения;
• сфера инфраструктуры и др.

Дальнее окружение оказывает существенное влияние на проект, как через предприятие, так и непосредственно напрямую. К факторам внешнего окружения относятся:

• политические факторы;
• экономические факторы;
• общество;
• законы и право;
• наука и техника;
• природные и экологические факторы.

В зависимости от типа и вида проекта факторы окружения проекта оказывают на него различное влияние. В таблице 3.1 приведены экспертные данные о степени влияния факторов окружения проекта для основных типов проектов сопоставимых масштабов [6].

Таблица 3.1 – Степень влияния факторов окружения для различных проектов

Из анализа этих данных можно сделать выводы:

• наибольшему влиянию внешнего окружения подвержены социальные и инвестиционные проекты, затем организационные, экономические, в меньшей степени – инновационные;
• наибольшее влияние на проекты оказывают: экономика, законы и право, затем культура, что несколько неожиданно, и только после этого политика и общество;
• наименьшее влияние на проекты оказывают природа, экология и инфраструктура.