Блог

Я переключился с Apache на веб-сервер Nginx. Как настроить постоянные ссылки в блоге WordPress?

WordPress обладает способностью создавать собственную структуру URL для ваших сообщений в блоге и архивов. Существует три основных типа постоянных ссылок WordPress:

• Ugly: https://itfb.com.ua/faq/?p=2284
• Часто используемые mod_rewrite: https://itfb.com.ua/faq/bash-for-loop/
• Практически, используя PHP PATHINFO: https://itfb.com.ua/faq/index.php/bash-for-loop/

В настройках ? Панель Permalinks (Постоянные ссылки) , вы можете выбрать одну из наиболее распространенных структур постоянной связи следующим образом:

Как использовать «Привлекательные» ссылки с Nginx?

Измените файл nginx.conf, запустите:

$ sudo vi /etc/nginx/site-enabled/itfb.com.ua.conf

Редактировать / добавить /  следующий блок местоположения в блоке сервера:

  Location / {
             Try_files $ uri $ uri / /index.php?$args; 
 }

Если ваш блог WordPress находится в /faq/ подкаталоге, попробуйте:

  Location / faq / {
             Try_files $ uri $ uri / /faq/index.php?$args; 
 }

Сохраните и закройте файл. Перезагрузите сервер nginx , запустите:

$ sudo systemctl reload nginx

ИЛИ

$ sudo /usr/sbin/nginx -s reload

Вот мой пример файла конфигурации:

# Upstream to abstract backend connection(s) for PHP.
upstream php {
server unix:/run/php/php7.0-fpm.sock;
}
server {
server_name www.itfb.com.ua;
root        /var/www/html;location /faq/ {
try_files $uri $uri/ /faq/index.php?$args;
}#Add trailing slash to */wp-admin requests.
rewrite /faq/wp-admin$ $scheme://$host$uri/ permanent;# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires max;
}# Pass all .php files onto a php-fpm/php-fcgi server.
index index.php;
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
# This is a robust solution for path info security issue and works with "cgi.fix_pathinfo = 1" in /etc/php.ini (default)
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php;
}
}

Администрирование и поддержка web серверов, office@itfb.com.ua

Hyper-V появился в Windows 2008 значительно расширив функционал Windows сервер. Еще бы – средство виртуализации, использующее аппаратные ресурсы, да еще и бесплатное (если Вы конечно купили windows сервер для прочих нужд) смогло со временем составить достойную  конкуренцию лидеру систем виртуализации VMware.

На данный момент в Windows Server 2016 работает версия 10тая версия Hyper-V

И за эти 8 лет появилась масса полезных функций и улучшений. Наиболее значимые из них, по мнению автора – это :

• Поддержка виртуальных машин Linux
• Живая миграция виртуальных машин между узлами кластера.
• Репликация виртуальных машин
• Управляемые виртуальные свичи
• Появление виртуальных машин второго поколения
• Общие VHD
• Контейнеры Windows

А также много других, не менее полезных в эксплуатации функций. О каждой из них можно рассказать много интересного. Но, чтобы было больше пользы – нужно более глубокое погружение.

Сегодня мы поговорим о работе виртуальных машин linux в среде виртуализации Hyper-V. Давайте начнем с конкретной задачи. Для автоматизации развертывания некоторой среды мне понадобилось создать несколько машин с операционной системой CentOS (была использована версия 7.3)

Был скачан требуемый дистрибутив, создана виртуальная машина второго поколения. И.. Виртуальная машина не запустилась. О чем говорит этот пример? О том, что нужно не забывать читать инструкции и Best Practices при изучении и развертывании новых продуктов. В моем случае проблема была с некорректной настройкой Secure Boot виртуальной машины. (Рисунок и пояснение Secure boot)

Secure boot позволяет быть уверенным, что ПО выполняющее старт ОС не скомпрометировано. Это эффективно защищает от внедрений зловредного софта в загрузчик системы.

Процесс загрузки сервера происходит следующим образом:

1. Запускается аппаратная часть.
2. Контроль передается BIOS, которая проверяет основные компоненты CPU, память, диски и другое оборудование.
3. BIOS читает настройки загрузки и перебирает все полученные в списке устройства в поисках загрузчика в нулевом секторе.
4. Если загрузчик ОС найден BIOS загрузке его в память и передает CPU для обработки.
5. Загрузчик запускает систему.

Это очень упрощенная, но понятная для понимания схема. Уязвимость появляется на 4ом шаге, когда BIOS завершает свою работу. В этот момент никто не заботится о том, что будет дальше.  И этим пользуются различные руткиты – это программные прокладки, обычно вредоносные, которые находятся между BIOS и операционной системой. ОС не может на них воздействовать, потому что они находятся вне зоны ее контроля, однако они могут перехватывать любые нажатия клавиш и обращения к устройствам.

С появлением UEFI ситуация изменилась. UEFI ищет не просто код в секторе 0, он ищет определенные файлы и имеет возможность выполнять некоторую их обработку, а не просто передавать их на выполнение CPU.

Secure Boot сочетает расширенные возможности загрузки и обработки с криптографическими возможностями UEFI. Ключи шифрования хранятся в прошивке. Когда UEFI запускает загрузчик ОС, он может проверить криптографическую подпись этого загрузчика ОС, если таковая имеется, ключами подписавшего, о которых он знает. Если образ был подписан доверенным ключом, UEFI разрешит его запуск. В противном случае он останавливает весь процесс загрузки и сообщает об этом.

Размножение виртуальных машин не составляет большого труда, если использовать команду PowerShell New-VM , однако здесь есть несколько подходов:

1. Создать образ CentOS с «тихой» установкой.
2. Установить и подготовить ОС на диске VHD и использовать диск при создании новых виртуальных машин.

Поскольку автор (в силу сложившихся обстоятельств) предпочитает платформу Windows всем остальным решениям, второй вариант был принят как основной. И следующей задачей была подготовка правильного образа-шаблона. В процессе установки ОС использовался режим Minimal Install, был создан раздел 20 ГБ, задан пароль для пользователя root и создан пользователь с правами root. Остальные настройки, в том числе конфигурация безопасности, планировалось выполнять в процессе дальнейшей конфигурации машины. Для создания шаблона было выполнено несколько шагов:

1. В файл /etc/sysconfig/network добавлен следующий текст:

NETWORKING=yes
HOSTNAME=localhost.localdomain

2. В файл конфигурации сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-eth0 добавлен следующий текст:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no

Последняя строка отключает NetworkManager.  Это необходимо для того, чтобы Hyper-V мог выполнить статическую настройку сетевого интерфейса.

3. Выполнена команда для удаления правил udev. Эти правила приводят к появлению проблем при клонировании виртуальной машины в Hyper-V или Microsoft Azure.

sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules

4. Очищены все текущие метаданные yum и установить все обновления с помощью команд

sudo yum clean all
sudo yum -y update

5. Выполнена настройка фаервола

firewall-cmd –zone=public –add-port=22/tcp

6. Выполнена установка Hyper-V tools.

sudo yum install hyperv-daemons

На последнем пункте стоит остановиться подробнее. Изначально установка тулов не планировалась из расчета, меньше ПО – меньше поломок. Но это подход не правильный. Не смотря на то, что CentOS 7 большинство фитч поддерживает без установки дополнительного ПО, на практике оказалось, что есть проблемы с созданием Snapshot’ов, которые к слову начиная с версии win 2012 называются Checkpoints. Также в моем сценарии виртуальные машины получают IP адрес по DHCP, следовательно, для дальнейшего подключения к ним нужно знать адрес, который получил виртуальный сервер. Получить его можно средствами PowerShell.

Кстати, в последней редакции Windows Hyper-V появилась функция PowerShell direct, которая позволяет управлять виртуальной машиной с Hyper-V хоста через PowerShell. Windows PowerShell Direct работает между хостовой и виртуальной машиной. Это означает, что ему не требуется сетевых настроек или настроек фаервола, он работает благодаря настройкам для удаленного подключения. Windows PowerShell Direct является альтернативой для инструментов, с помощью которых администраторы  Hyper-V подключаются к виртуальной машине с Hyper-V хоста:

• Remote PowerShell и Remote Desktop
• Hyper-V Virtual Machine Connection (VMConnect)

Эти утилиты работают хорошо, но имеют свои недостатки: VMConnect и Remote Desktop сложно использовать при автоматизации. Remote PowerShell сложен в установке и обслуживании. И значимость этих недостатков растет с ростом инфраструктуры  Hyper-V. Windows PowerShell Direct предоставляет мощные возможности скриптования и автоматизации вместе с простотой использования VMConnect.

Получить IP адрес машины можно используя, например, следующий  набор командлетов

Get-VM |?{$_.VMName -like “LAB2-CentOS7*”} | Get-VMNetworkAdapter | ft VMName, IPAddresses, switchName -autosize

При этом получим такой вывод:

До установки тулов поле IPAdresses было пустым (как у виртуальной машины LAB2-CentOS7-Template). Нужно также отметить, что это поле заполняется не сразу после установки, а через некоторое время. Поэтому особо нетерпеливым (таким, как я J ) рекомендуется попить чаю перед тем, как начать паниковать при отсутствии ожидаемого результата.

Также я хочу отдельно остановиться на установке тулзов еще и потому, что у меня это вызвало некоторые трудности. Доверяя Microsoft, 14.03.2017 hyper-v tools были  скачаны мною с официального сайта Microsoft, распакованы и установлены согласно имеющейся инструкции. Однако после перезагрузки CentOS 7.3 упрямо и безуспешно пыталась грузиться в emergencyMode. Был выполнен ряд действий, описанных в разделе инструкции Known Issues. Однако результат не был достигнут. После изучения проблемы и примеров ее решения, окрашенных, мягко скажем, нелицеприятными эпитетами в сторону Microsoft, меня посетила идея установки hyper-v tools из репозитариев CentOS. Одна единственная команда решила мою проблему.

yum install hyperv-daemons

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

Вот собственно и все. Задача по настройке Hyper-V и виртуальных машин Linux решена.

С удаленной машины я подключаюсь PowerShell скриптом к Hyper-V хосту, выполняю создание нескольких машин, копирование и подключение для каждой из них шаблонного VHD, запуск всех созданных машин и получение их IP адресов, которые потом передаются в Ansible для дальнейшей конфигурации системы. Но это уже совсем другая история.

Конечно же, многое о hyper-V осталось за кадром. Поэтому мы обязательно продолжим в будущих публикациях. А если у Вас появились вопросы – наши специалисты всегда готовы ответить на них.

Мы предоставляем услуги внедрения и поддержки систем виртуализации, office@itfb.com.ua

Темой этой публикации будет один из продуктов для хостинга исходного кода проектов. А именно GitLab. Мы затронули эту тему, так как она актуальна для devops. Существует несколько решений с подобным функционалом. Опытные разработчики расставляют их в порядке популярности так:

1. GitHub
2. BitBucket
3. GitLab

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

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

GitLab также имеет бесплатные приватные репозитарии. Может быть установлен локально. И не смотря на то, что это сравнительно молодой проект, который имеет немного внешних интеграций, он выглядит достаточно привлекательным для внутреннего использования.

GitLab включает в себя управление Git репозитарием, отслеживание задач, code review, IDE, activity streams, wikis, и многое другое.

GitLab также имеет встроенные CI и CD средства для тестирования, сборки, и развертывания Вашего решения, включая удобные инструменты для мониторинга процесса на всех этапах. Вы будете уверены в том, что Ваш код будет работать в различных окружениях.

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

В качестве преимуществ в работе с GitLab профессионалы отмечают:

1. Наличие Issues для проектов и Snippets (аналог Gist) на приватном сервере.
2. Удобство работы с Merge Requestsв графическом представлении
3. поддержка Docker и инструмент для Continuous Integration из коробки.
4. ключи для чтения репозитория во время деплоя
5. Наличие преднастроек для интеграции с другими сервисами (JIRA, Asana, HipChat и т.д.)

Среди нового функционала GitLab стоит упомянуть об автоматическом развертывании через планировщик контейнеров. С включением этого функционала появляется кнопка, нажимая на которую Вы создаете merge-requqest содержащий сценарий развертывания с помощью докер. В шаблоне для merge-request’а имеется настройка ReviewApps, которая позволяет посмотреть на работу новой фитчи до того, как будет принят merge-request.

Также полезен Web-терминал для динамических сред, созданных для проектов, с которыми Вы ведете работу. Доступ к нему Вы можете получить прямо со страницы проекта. При нажатии на кнопку подключения GitLab установит SSH соединение с требуемым сервером и отобразит консоль в окне браузера.

С появлением глобальных git-хуков больше не нужно копирование правил и триггеров для пушей из проекта в проект. Один раз созданные хуки в директории hooks/<hook_name>.d/ будут доступны для каждого проекта в инстансе GitLab. Также появилась возможность создания упорядоченных хуков, где последующие хуки не выполняются, пока предыдущий не  завершится успехом.

GitLab 8.16 можно развернуть в Google Container Engine. В нём сразу будет автомасштабируемое CI, автоматическое развертывание в ваш собственный кластер Kubernetes, чаты Mattermost, поддержка приватного реестра Docker и настройка сертификатов с помощью Let’s Encrypt.

Также появилась  возможность Мониторинга GitLab с помощью Prometheus. Для ее использования на данный момент необходима некоторая переконфигурация GitLab, однако в версии GitLab 9.0, которая запланирована на 22 марта 2017 года, мониторинг будет включен по умолчанию.

Что ж, ждем новых улучшений.

Почему именно эта пара, спросите Вы? Потому что популярность open source решения в области баз данных на протяжении нескольких последних лет растет, в то время как коммерческие решения показывают спад. Потому что выбранные решения представляют собой разные типы баз данных, а еще потому что несколько дней назад мой брат, начинающий разработчик, спросил меня об этом.

Что ж, вопрос не простой, потому что многогранный. Попробуем разобраться.

Автор одного из докладов на Highload++ 2016 предлагает рассмотреть перечень вопросов, оценив ответы на которые можно склониться в пользу того или иного выбора базы данных для своего проекта.

1. Опыт и предпочтения команды. Это достаточно выжный момент, поскольку для многих решений подхоит как MySQL так и MongoDB. Однако если Ваша команда все время работала с MySQL, например, то ресурсы, которые потребуются на переучивание, буудут потрачены впустую, поскольку не принесут явной выгоды.
2. Подход к разработке и жизненный цикл приложения. Сейчас в тренде быстрый подход к разработке с дальнейшим постоянным внесением изменений. И конечно же mongoDB выглядит перспективнее в этом свете. Но нужно понимать, что у данных всегда есть схема, вопрос только в том, где она реализуется.
3. Модель данных. Казалось бы mongoDB со свойе простой структурой должна иметь преимущество и в этом вопросе. Но MySQL – реляционная база данных, позволяющая легко отображать связи между таблицами, нормализировать данные, что в итоге позволяет выполнять изменения только в одном месте, в то время как в mongoDB придется вносить изменения в кучу документов. Вопрос в том, что данные не всегда удается уложить в реляционный вид или это не так нужно. В качестве подтверждения этого факта можно привести примеры, когда в ячейках таблицы хранится JSON или XML текст.
4. Транзакции и консистентность. Здесь надежнее выглядит MySQL, который работает с транзакциями и позволяет гибко управлять ими. Документация MongoDB говорит о поддержке ACID-транзакций, но с ограничением. На деле это выглядит так: mongoDb вносит изменения в файл. Операция атомарна. Но если нужно внести изменения в несколько файлов и во время операции произошел сбой, то Вы никак не защищены от того, что часть файлов будет изменена, а часть – нет. Консистентность также делается на уровне документов.
5. Производительность. Достаточно сложно сравнить, поскольку в зависимости от схемы базы данных будет меняться дизайн приложения. Однако следуя правилу «чем приложение проще масштабируется, тем меньше внимания уделяется его эффективности», можно утверждать, что MySQL будет более экономен к ресурсам при одинаковых объемах данных.
6. Масштабируемость. Как было сказано в предыдущем пункте, MongoDB изначально фокусировался на масштабировании, что, конечно же, сказалось на качестве и удобстве использования, в то время как для MySQL – это «вынужденная мера» требующая особого внимания разработчиков.
7. Администрирование. MySQL имеет богатство решений и гибкость. Это может быть как плюсом, так и минусом, поскольку разнообразие вызывает трудности. В mongoDB есть ориентация на стандартизацию, что конечно же минимизирует администрирование.

Подводя итог, можно  сказать, что однозначного выбора в пользу той или иной БД нет. Нужна оценка каждого конкретного случая с учетом особенности архитектуры проекта и команды, которая работает над ним. Возможно даже применение гибридных решений, однако помните, что этим не стоит увлекаться, поскольку в погоне за использованием лучших сторон каждого из продуктов может быть потеряна простота разработки решения.

Какую бы базу данных Вы не выбрали, наша команда профессионалов, может установить, настроить отказоустойчивое решение и предложит поддержку, office@itfb.com.ua

Jenkins – лидер среди решений автоматизации с открытым исходным кодом, Дженкинс предоставляет сотни плагинов для поддержки, создания, развертывания и автоматизации любого проекта. Сам Jenkins написан на Java и, по субъективным оценкам пользователей, является, мягко скажем, не самым быстрым решением непрерывной интеграции для девопс

Однако это достаточно гибкий  инструмент, который применяется для автоматического выполнения различного рода задач. Для проектов по разработке это могут быть тесты сборок, проверка ошибок, генерация отчетности и документации и многое другое. Например, нетипичным, но вполне рабочим решением является использование Jenkins в качестве системы мониторинга. Почему это возможно ? Потому что задачи для Jenkins описываются в файле xml. После формирования файла сервер по расписанию или вручную выполняет его содержимое. Каждая задача содержит набор команд: например, создание папок и запуск скрипта инсталляции приложения.

Как было сказано выше, Для интеграции с другими системами и расширения функционала Jenkins имеет большое количество плагинов. Так, в случае автоматизации задач, связанных с разработкой необходимо работать с репозитариями. Для каждого из которых есть свой плагин.

Вообще, для общего понимания стоит сказать, что сам Jenkins ничего не умеет, он только управляет другими процессами и плагинами. Например, если Вы боритесь за чистоту кода в PHP проекте, Вас может заинтересовать следующая конфигурация:

На Linux сервере установлен Jenkins, пакеты PHP CodeSniffer, PHP Mess Detector, PHP Copy/Paste Detector и подобные, создан скрипт, с помощью которого будут запущены вышеперечисленные пакеты с определенными параметрами и получен результат.

С точки зрения Jenkins в таком случае нужно будет создать проект-задачу, которая подтянет новую версию с хранилища кода, запустит процесс сборки, что в нашем случае будет означать проверку PHP кода с помощью вышеозвученных пакетов, распарсит полученные результаты работы скрипта с помощью плагинов, заданных в Post-Built Actions при создании задачи. Там же можно указать необходимость рассылки уведомлений о результатах работы.

Конечно же на практике все немного сложнее: например для того, чтобы работала рассылка уведомлений нужно указать в настройках сервера параметры SMTP. Но поскольку основная цель этой публикации – показать принцип работы продукта Jenkins, эти и многие  другие нюансы остаются за кадром.

Автоматизируем процесс непрерывной интеграции, office@itfb.com.ua

После установки Jira Core (описанной в предыдущей статье из цикла статей инструменты для DevOps) необходима базовая настройка для работы с заявками.

Итак. С чего начать.

Начинать ( как и во многих случаях при конфигурации ИТ систем) лучше с чистого листа бумаги. На нем Вы изложите структуру Вашей компании (той ее части, которая будет работать с JIRA), опишите функционал каждой группы сотрудников. Также необходимо будет описание жизненного цикла заявки: Как она попадет в систему, кем будет обрабатываться, кем будет согласовываться и контролироваться. Не лишним будет продумать, какие типы заявок и какие поля в задаче будут нужны. Такое планирование необходимо, если вы не хотите потом переделывать заново. Если вы не готовы ответить на эти вопросы, я рекоменудю вам проконсультироваться с опытными архитекторами подобных решений. Наша компания, как всегда к вашим услугам J Или же начать с самого простого, и посмотреть в процессе работы, что вам потребуется. Но помните. Это долгий путь. И помните, что рано или поздно вы можете прийти к мысли о том, что все это нужно удалить, спланировать и установить заново.

В прошлой статье мы остановились на экране:

Еще момент: я буду строить систему управления задачами для небольшой компании, занимающейся оказанием услуг в сфере ИТ. Компания находится на стадии роста со всеми вытекающими «болезнями» детского периода. Поскольку в компании все делают все, то создадим 1 проект,  и назовем его «Котел», в котором будут вариться наши задачи.

Приступим к настройке Jira. После того, как я  нажала кнопку «Создать новый проект» система предложила мне 3 шаблона  проекта, по сути отличающихся только бизнес-процессом (то есть жизненным циклом задачи). Их можно охарактеризовать как Простой, Средний и Сложный. Был выбран Средний вариант, указано имя проекта и проект готов.

Далее. С этим проектом должен кто-то работать. Давайте знакомиться. (Все имена вымышлены, а совпадения случайны). В моей компании есть Директор. Его зовут Виктор. Он является генератором идей, тепловозом, который заставляет компанию двигаться вперед, а еще выполняет обязанности связанные с поиском клиентов, заключением договоров, поиском сотрудников, развитием компании, ведением проектов и прочей рутиной каждого сотрудника компании. Частенько норовит часть задач спихнуть на других. Таня – занимается развитием компании: продвижением информационных ресурсов, подготовкой коммерческих предложений, является контактным лицом для всех клиентов, которые приходят с информационных ресурсов, подхватывает задачи, упущенные Виктором. Роман – ответственный за финансовую сторону вопросов. Максим – технический специалист, поддерживающий внутреннюю инфраструктуру компании. Роман и Максим могут выступать в роли руководителей проектов, а также вместе с Таней заниматься решением технических задач различного уровня сложности. За каждым из членов команды могут стоять «роботы», то есть специалисты различных областей, которые занимаются только выполнением конкретно поставленных задач.

Создадим пользователей для каждого члена команды и две группы: «Команда» и «Роботы». В группу Команда добавим созданных пользователей. А группу Роботы будем наполнять по мере создания новых пользователей для выполнения конкретных задач.

Перейдем к настройке Jira, а именно в раздел «Администрирование» -> «Управление пользователями» (скриншот с готовыми пользователями и группами) Совет: При работе с системами авторизации заранее продумывайте политики именования учетных записей и других объектов. Четкие правила позволят избежать путаницы и упростят автоматизацию, когда масштабы системы разрастутся.

Теперь нужно настроить Jira так, чтобы нужные пользователи умели выполнять нужные задачи. За это отвечают схемы безопасности.  Хотелось бы, чтобы Команда видела все задачи, Роботы видели только каждый свои задачи. А задачи, касающиеся бухгалтерии видели только Виктор и Роман.

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

Создам новую схему безопасности задачи myISS, в которой создам несколько уровней безопасности:

• myISL_Standard (по умолчанию)
• myISL_Buh

Теперь перейдем к схеме распределения прав самого проекта. Проект «Котел» использует Default Permission Scheme. Значения выставленные по умолчанию достаточны для начала работы. Однако для того, чтобы заработали настроенные нами ограничения, нужно при создании задачи разрешить установку Issue Security.

Теперь я готова пройтись по основным настройкам проекта. Я:

• Изменю Project Lead и Default Assignee. Им будет Виктор.
• Добавлю созданную ранее схему безопасности задач в разделе Permissions.
• Поработаю с жизненным циклом задачи, чтобы адаптировать его под наши нужды.

Если с первыми 2мя пунктами все понятно, то по последнему – стоит пояснить. В нашей компании наблюдается острая нехватка контроля выполнения задач. Задачи ставятся, выполняются и … забываются. В связи с чем, хочется сделать акцент на финальной точке. Нужно чтобы автор задачи подтвердил качество ее выполнения. Поэтому к стандартному Workflow для задач нашего проекта, который, к слову, выглядит так:

Необходимо добавить еще 1 статус «Close». Сделаем это:

Теперь наш Workflow выглядит так:

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

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

Система готова для использования, а как сделать ее более удобной –читайте в наших будущих публикациях или обращайтесь за помощью к нашим специалистам office@itfb.com.ua