1. Главная страница » Компьютеры » Nfr лицензия что это

Nfr лицензия что это

Автор: | 16.12.2019

Начиная со статуса Бизнес-партнер, вы можете получить NFR-версию (версия не для продажи) Битрикс24 для своей компании совершенно бесплатно.

Зачем устанавливать бесплатный Битрикс24?

1. Самостоятельно изучить возможности Битрикс24 и обучить своих сотрудников.

2. Организовать работу внутри вашей компании с помощью 12 рабочих инструментов.

3. Пригласить клиентов на ваш портал и продемонстрировать все возможности Битрикс24 в действии.

5. Получать заявки на внедрение Битрикс24 с нашего сайта от клиентов прямо в CRM вашего Битрикс24.

Сделайте первый шаг навстречу успешным продажам и установите NFR-лицензию на Битрикс24.

Прочитав предыдущую статью о том, как заключить партнёрство с 1С-Битрикс и выполнив нужные шаги, вы уже максимально приблизились и к цели этой статьи. Здесь будет рассказано про саму NFR-лицензию, о путях её получения и о способах её продления.

Что такое NFR-лицензия?

Это бесплатная полнофункциональная лицензия, которую можно использовать для своих нужд, как например, собственные проекты, обучение и ознакомление клиентов с Битриксом, песочница для тестов. Самым важным условием её использования является то, что её нельзя продавать клиентам.

Пути получения

Существует два пути и, в зависимости от выбранного, существует также два пути продления.

По запросу

Один раз после получения заключения партнёрства можно сделать запрос на получение бесплатной лицензии.

Для этого нужно:

  • Подписать партнёрский договор. Этот процесс описан здесь
  • Получить сертификаты:
  • Администратор.Базовый
  • Администратор.Модули
  • Администратор.Бизнес
  • Разработчик Bitrix Framework
  • Технология Композитный сайт
  • Иметь свой сайт на демо версии "1С-Битрикс: Управление сайтом" с выполненными на нём требованиями.
  • Требования к сайту:

    • Оригинальный дизайн (то есть не стандартный шаблон и не чья-то копия)
    • Страница о вашей компании с переченем предоставляемых услуг
    • Информация о том, что вы партнёр 1С-Битрикс
    • Описание всех редакций CMS Битрикс (пример)
    • Логитип 1С-Битрикс (пример)
    • Текст «Работает на «1С-Битрикс: Управление сайтом» и ссылку на http://www.1c-bitrix.ru/products/cms/ на всех страницах, например, в футере

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

    По статусу

    После получения статуса сертифицированного партнёра, вы получаете 2 NFR-лицензии редакции «Бизнес», без каких-либо запросов, вам отправят ключи на указанную в карточке почту.

    Получив позднее золотой статус партнёра, вам высылается ещё 2 NFR-лицензии редакции «Бизнес» в дополнение к двум предыдущим.

    Способы продления активности лицензии

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

    По запросу

    В этом случае надо продать (то есть купить у Битрикса) лицензии на двухкартную сумму стоимости лицензии, которую вы получили без учёта скидок. Также нужно сохранить на сайте те же требования, что и при получение CMS. Для примера, редакция "Эксперт" стоит 40 900 рублей, то есть надо продать копий на сумму 81 800 рублей.

    По статусу

    Необходимо подтвердить статус, то есть получить ещё 100 баллов или 500 баллов для сертифицированного и золотого статуса соответственно. Если вы были золотым партнёром, но заработали меньше 500 баллов, то продлеваются только две первых лицензии, так как ваш статус падает до предыдущего.

    Битрикс24

    Также можно получить NFR-лицензию на Битрикс24 (это crm), так же по прямому запросу или одну лицензию при получении статуса. Здесь нет важных требований, как в случае с системой управления сайтом, главное не путать понятия CRM и CMS.

    Тонкие моменты

    Битрикс, говорит, что фрилансер может получить копию лицензии не подписав договор, но на практике мне пришлось подписывать.

    Можно также получить NFR-лицензию мобильного приложения, но только после получения одного из двух партнёрских статусов.

    Также при получение надо отправить письмо-подтверждение в 1С-Битрикс, как согласие с условиями лицензионного соглашения. Чтобы ускорить процесс, можно отправить электронный скан техподдержке. Ниже приведён примерный шаблон письма.

    Генеральному директору ООО "1С-Битрикс"
    Рыжикову С.В.
    От генерального директора _
    _

    Данным письмом подтверждаем, что копия программного продукта "1С-Битрикс: Управление сайтом" (NFR-ML-1OS7LNS7SKKKZR4ZG) будет использована в соответствии со всеми требованиями лицензионного соглашения только на сайте http://ИМЯ.ru.
    Обязуемся в течение года обеспечить продажу продуктов компании "1С-Битрикс" на сумму, не менее чем в два раза превышающую стоимость указанной копии программного продукта.
    Дата, подпись директора компании, расшифровка, название компании, печать"""

    Читайте также:  Ip адрес микротик по умолчанию

    Заключение

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

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

    Далее опишу основные проблемы, с которыми пришлось столкнуться в этом, и нескольких похожих, проектах, апробированные мною решения и результаты работ.

    Исходные данные:

    • Есть интернет-магазин на 1С-Битрикс
    • Проекту несколько лет, но только несколько месяцев назад сайт перевели на 1С-Битрикс
    • Посещаемость 10-15 тыс. человек в день
    • Каталог магазина содержит около 12 000 позиций товаров
    • Простои и отключения сайта недопустимы
    • Проект в течении полугода разрабатывался другой компанией:
      1. Есть ТЗ, примерно на 100 листов, соответствующее выполненной работе примерно на 40%
      2. Никакой документации проекта
      3. Отсутствие понимания, почему предыдущие разработчики использовали именно такие архитектурные решения.

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

      Первым делом, получил доступ исходному коду проекта. Поверхностно проанализировал. Согласовал с заказчиком список первостепенных задач. Составил план разработки для 3х разработчиков и, как сказал Гагарин, поехали!

      Проблема №1 – во всем виноваты разработчики

      Как это обычно и бывает, во всем виноваты все, кроме заказчика. Дизайнер сделал макет, который слишком много весит, хостер предоставил сервер, который медленно работает, разработчики сделали сайт, который все время глючит и ломается, менеджеры выполнили какие-то задачи, которые мы выполнять не просили, после перехода со старой версии сайта на 1С-Битрикс произошло резкое снижение поискового трафика и т.д. Ситуация не однозначная. С одной стороны основная ответственность конечно же должна лежать на компании разработчике. Нужно было донести до заказчика последствия всех действий с сайтом и подготовить к результату. При выполнении работы предложить целостную архитектуру будущей системы и план разработки, которого нужно придерживаться до завершения основных этапов. Провести тщательное тестирование функционала и сдать работу. С другой стороны, не редко сталкиваюсь с ситуацией, когда заказчик все сам лучше знает, потому что у него мама когда-то рисовала, а посему является лучшим дизайнером, и его 7ми летний сын прекрасно разбирается в SEO-оптимизации, потому что все время проводит за компьютером, играя в GTA.

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

      В результате:

      • Проект не доведен до логического завершения. Многие задачи брошены на середине пути
      • Проект не задокументирован. Работа части функционала не очевидна. При разработке нового функционала оказывается, что перестал работать функционал, который раньше работал и о существовании которого новый разработчик и не подозревал
      • Часть написанного предыдущим исполнителем кода приходится переписывать с нуля
      • Задуманная архитектура проекта в первые недели/месяца работы новому подрядчику не ясна. Доработка функционала одного модуля приводит к потере работоспособности функционала никак не связанного с ним модуля
      • Заказчик нервничает, исполнитель нервничает, посетители не довольны, посещаемость уменьшается, продажи падают

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

      Проблема №2 – параллельная разработка.

      В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки. Проблема заключается в том, что разработка ведется несколькими, в моем случае, тремя, разработчиками непрерывно. В случае с классической разработкой все просто. Каждый разработчик занимается своим модулем. Затем проводится функциональное тестирование каждого модуля, все доработки сливаются в репозиторий какой-нибудь системы контроля версий, дальше это тестируется все вместе (интеграционное тестирование). Если результат нормальный –тестовая версия презентуется заказчику. После принятия тестовой версии происходит обновление продакшен-сервера. В соответствии с методологией SCRUM я определил, чтоб буду выкладывать новые версии на боевой сайт раз в неделю. Соответственно, есть 3-4 дня на основную разработку. 1 день на тестирование и исправление ошибок и пол дня на обновление боевого сервера. Сроки конечно колеблются, но правила «релиз каждый четверг» старался четко придерживаться.

      Читайте также:  Eclipse manager windows 10 что это

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

      Как же быть с лицензией? Обратился в техническую поддержку 1С-Битрикс. Получил предложение докупить доп. лицензии для разработки. Мягко сказать, не обрадовался, но других предложений не получил. Выход нашел достаточно быстро. Решил использовать NFR-ключи. Благо, партнерский статус позволяет. В результате создал 5 исталяций интернет-магазина:

      • Продакшен-сервер
      • Тестовый сервер
      • 3 сервера разработки (по одному на разработчика)

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

      Сейчас использую следующую схему:

      • Каждый разработчик использует для работы только свою локальную копию
      • В оговоренное время все завершенные доработки сливаются в общую ветку в репозитории
      • QA забирает себе «смердженную» версию для тестирования
      • После тестирования и исправления ошибок происходит обновление демонстрационного сервера для заказчика
      • После проверки и акцепта заказчиком, доработки переносятся на боевой сервер.

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

      По мере построения схемы столкнулся с еще одной проблемой. Проект занимает на диске около 80Гб. Без кеша и временных файлов – около 60. Пытался по началу убрать картинки и видео из контроля версий – не получилось. Информация на сайте меняется постоянно. Тестировать нужно на актуальных данных. Первый комит сайта в репозиторий у меня шел кусками более 2х суток. Первый чекаут в папку для разработки проходит несколько часов (SVN сервер в локальной сети разработки). Если, не дай бог, случайно сделать полный апдейт папки проекта – можно уходить курить, обедать, играть в пинг-понг или керлинг. Комит только выбранных файлов или папок проходит достаточно быстро. Решение: выполнил задачу – закомить сразу десяток измененных файлов.

      Проблема №3 – обновление продакшен-сервера и совместная работа с заказчиком

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

      Тут отлично работают законы Мерфи:

      • Если что-то плохо работает на тестовом сервере – на боевом сервере это обязательно сломается.
      • Если что-то отлично работает на тестовом сервере – на боевом сервере это все равно обязательно сломается.
      • Если баг на сайте существует всего 5 секунд, его обязательно найдет кто-то из посетителей и обязательно напишет об этом в отзывах или в форме обратной связи.
      • Если сайт не работает 1 минуту во время обновления, то именно в эту минуту владелец компании будет показывать его своему другу или конкуренту (и это не смотря на согласование времени и процедуры обновления).

      Я, конечно, утрирую, но в каждой шутке есть доля шутки. Минимальная нагрузка на сайт с 4 до 6 утра. Обновлять в это время конечно бы лучше, но уж очень не хочется.

      В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части:

      • Обновление программного кода
      • Обновление базы данных с помощью SQL-скриптов

      В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут. Можно конечно апдейтить только измененный файлы, но тогда теряется весь смысл репозитория. Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку. А это всегда медленно, нужно помнить все изменения, которые необходимо выполнить, велика вероятность случайно ошибиться. Можно, конечно, написать SQL скрипт, который сам внесет все нужные изменения в базу. В простейших случаях, разумеется, так и делаем. Но в большинстве случаев написание и отладка такого скрипта занимает больше времени чем сама разработка и намного больше времени, чем выполнение всех действий вручную с последующей проверкой.

      Читайте также:  Dell inspiron 5368 обзор

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

      Второе, с чем столкнулся, это совместная работа с заказчиком. Т.к. проект большой, над ним постоянно трудится около 30 человек. Контент-менеджеры, менеджеры по продажам, SEO-оптимизаторы, маркетологи и много еще кого. Естественно, каждый вносит в страницы сайта и настройку модулей какие-то изменения. Первым решением было забрать права у заказчика на внесение изменений в программный код сайта. Решение абсолютно правильно, но стало только хуже. Если раньше заказчик предполагал, что он так же может зайти на сайт и случайно что-то сломать, то теперь все шишки стали сыпаться только на нас. При чем. Даже если контент-менеджер криво отредактировал текст на странице и не закрыл какой-то тег – все равно виноват разработчик. Решение нашлось довольно простое. В маркетплейсе есть бесплатны модуль по контролю версий страниц. Проблему это не убрало, все равно кто-нибудь время от времени что-то да наплужит, но зато теперь появилась возможность посмотреть в любой момент времени кто менял, что менял и почему все сломалось. Результат, конечно, не ice, но кучу нервов мне экономит.

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

      Проблема №4 – «сделайте мне срочно, это же задача на 5 минут»

      Проблема относится не столько к 1С-Битрикс, сколько к доработке и поддержке работающих проектов. Часто у заказчика возникает желание сделать какую-то мелочь, но срочно и сразу на боевом сайте. Результат всегда один – ничего хорошего из этого не выходит. В лучшем случае, об этой доработке просто забудут при очередном релизе, в худшем – сервер просто упадет и его придется несколько часов восстанавливать из бекапа.

      Решение нашел только одно – никогда не идти на поводу у заказчика в ущерб надежности и безопасности. Как бы заказчик не просил, виноват всегда будет разработчик. Как говорил мне мой бывший начальник: «Я же тебя не просил сделать плохо».

      И раз уж затронули тему бекапов, хочу заметить. Бекап средствами 1С-Битрик это конечно хорошо и удобно, но очень медленно. В случае, если срочно нужно восстановить 1-2 файла или несколько значений в базе, приходится ждать пока разархивируются все 60 Гб. Здесь наиболее эффективной мне кажется следующая схема:

      • Должен происходить ежесуточный бекап файлов и базы данных в виде архива на внешний источник данных.
      • Всегда делаем бекап непосредственно перед обновлением в одном из 2х вариантов:
        1. Вариант light – Копируем всю папку проекта в соседнюю папку на сервере. Базу данных в виде дампа сохраняем в отдельный файл. Ничего не архивируем. В случае, если нужно будет восстановить какое-то значение в базе или один из файлов, все будет под рукой и легкодоступно
        2. Вариант strong – аналогично предыдущему, только базу копируем в другую базу данных MySQL. Это позволит в случае полного краха за 1-2 минуты исправить в файле хостов корневую папку сайта и проект начнет работать из соседней папки с копией базы.

        Добавить комментарий

        Ваш e-mail не будет опубликован. Обязательные поля помечены *