Не могу не согласиться, но всегда есть особенности. Систему требовалось построить так, чтобы релиз срочного исправления не был стрессом для процесса и команды. На практике же, работы, ведущиеся по плану, выпускались 1-2 раза в неделю, иногда реже.
Что касается стабильности релизов, мы традиционно используем CI практику, что, является достаточным для обеспечения необходимого качества.
Стоит дополнить по первой части вопроса:
В этом конкретном случае ситуация, описанная в первом примере, не составляла проблем, т.к. проект действующий, с уже реализованными основными возможностями, мы занимались добавлением достаточно небольших улучшений и дополнений, попутно исправляя баги.
Разработка системы с нуля имеет свои особенности, и подобная схема работы может быть не так эффективна.
Что касается второй части вопроса, то тут желательно стараться максимально дробить задачи, как раз для того, чтобы иметь возможность сначала реализовать работающий костяк, а потом заниматься улучшениями. А в процесс это вписывается довольно просто — «улучшение задачи№1 — это задача№2»
Если релиз какой-то задачи не возможен без другой задачи, она ожидает на stage сервере, пока функционал не будет реализован полностью. После чего есть возможность провести полноценное интеграционное тестирование, затем на боевой сервер выносится группа задач
В данном случае был большой запас по аналитике, и в канбан цепочку мы ее не включали. Требования разрабатывались парралельно процессу разработки.
По поводу срочных задач — да, такое было довольно часто, мы старались не бросать незавршенные задачи, но иногда приходилось что-то ставить на паузу в пользу более срочной задачи.
Речь идет о подходе к разработке, а не о движке. Движок не заборшен, а переносится на другую платформу. Патчи к предыдущим версиям выпускаются.
Понравился набор фич «из коробки» — поддержка более 80 языков, практически готовая админка для управления движком (процесса индексирования, настройки релевантности, бустинг и т.д.).
На момент выбора платформы fast был наиболее подходящим решением.
Основное назначение этой статьи — показать подход к оптимизации затрат на ПО. Есть спорные моменты, согласен, но такие проекты (по управлению ПО-активами) нельзя делать под копирку, что и доказывают в очередной раз ваши комментарии. Спасибо вам за них, я обязательно учту в следующих статьях
Спасибо за отзыв. Средствам аудита можно посвящать отдельную статью, поскольку их такое количество, что поместить в одну статью, посвящённую другой теме, просто невозможно.
По второй части комментария. Нет, не всегда нелицензионный. Я поэтому и добавил слово «возможно». Т.е., ВОЗМОЖНО, используют нелицензионный, но я не могу утверждать это, лишь допуская такую возможность.
И свободных продуктов действительно много. Более того, иногда можно включать в стратегию возможность перехода к бесплатным продуктам по части приложений. Более того, считаю, что к софту надо относительно внимательно не только с точки зрения его покупки, но и с точки зрения оптимизации в плане перехода на свободное ПО. Если по фукнционалу сотруднику нужен простой текстовый редактор для использования в редких случаях, то зачем ему покупать MS Office для этого?
Это не выделенный сервер, а это виртуализированный сервер (облачный) на физическом сервере (но не VPS).
В отличие от выделенного сервера, позволяет легко мигрировать с площадки на площадку, легко масштабировать ресурсы под вашу нагрузку (процессорные мощности, память, дисковое пространство).
Сама суть услуги «Хостинг 1С» подразумевает предоставление сервиса и инфраструктуры заточенной под 1С и тяжелые базы данных (например выбор СХД- на SSD с большим показателем IOPS или обычных дисках), обеспечение прокидывания физических HASP ключей в «облаке» а так же обеспечение надежности и стабильности работы такого решения. Те (и это как правило) компании уже имеют ранее купленные программы 1С которую и переносят на наши площадки.
Мы можем предоставить и 1С в аренду, но это уже другая услуга (что уже массово представлена на рынке), но не настолько гибкое решение которое позволяет услуга «Хостинг 1С»
Сам доступ организован в режиме терминального доступа + root доступ. так как мы предоставляем вам саму инфраструктуру на которой вы размещаете и разворачиваете свою программу 1С + конфигурации. Далее вы можете управлять и организовывать доступы так как сочтете это необходимым для ваших нужд.
Вы совершенно правы что услуга подразумевает резервные площадки и кластеризацию, что обеспечивает стабильность работы и возможность миграции между площадками.
мы предоставляем инфраструктуру, ресурсы, и возможность выбора СХД и площадки, а принятие решения остается за вами что именно и где размещать. МЫ не контролируем ваш контент, поэтому вам решать готовы вы размещать то что не соответствует правилам и возможные риски или действовать с разумной осмотрительностью. Вот как раз ваш вариант «сервер в соседнем доме» не дает ни гарантии ни уверенности за сохранность…
но в полемику вдаваться не будем, каждый выбирает то что ему удобнее…
Мы работаем в рамках тех юрисдикций, правил и законов где размещаем наши площадки и ресурсы. Соответственно и действуем в рамках этих законов. как вы понимаете законы в россии и европе по разному регламентируют возможности и права для контролирующих органов. Но в любом случае мы действуем строго в рамках законов.
мы предлагаем вам выбор — разместить на российской площадке (но здесь остаются законодательные риски и от этого никто не застрахован) или на нашей европейской площадке, где законодательство более четкое и конкретное в части таких действий и позволяет избежать тех форм которые вы описали в своем посте)
Изначально многие не заметили поле с футболкой, поэтому мы поняли недочёт и сделали поле изначально пустым и обязательным для заполнения.
Тем, кто уже зарегистрировался, можно написать оргкомитету (http://sletadminov.ru/personal/3445/), они поменяют запрошенный размер в базе.
Что касается стабильности релизов, мы традиционно используем CI практику, что, является достаточным для обеспечения необходимого качества.
В этом конкретном случае ситуация, описанная в первом примере, не составляла проблем, т.к. проект действующий, с уже реализованными основными возможностями, мы занимались добавлением достаточно небольших улучшений и дополнений, попутно исправляя баги.
Разработка системы с нуля имеет свои особенности, и подобная схема работы может быть не так эффективна.
Что касается второй части вопроса, то тут желательно стараться максимально дробить задачи, как раз для того, чтобы иметь возможность сначала реализовать работающий костяк, а потом заниматься улучшениями. А в процесс это вписывается довольно просто — «улучшение задачи№1 — это задача№2»
По поводу срочных задач — да, такое было довольно часто, мы старались не бросать незавршенные задачи, но иногда приходилось что-то ставить на паузу в пользу более срочной задачи.
Понравился набор фич «из коробки» — поддержка более 80 языков, практически готовая админка для управления движком (процесса индексирования, настройки релевантности, бустинг и т.д.).
На момент выбора платформы fast был наиболее подходящим решением.
Начиная примерно с пятой версии Adobe Acrobat Reader был переименован в Adobe Reader для того чтобы отделить его от платных продуктов.
С тех пор бесплатный вариант называется Adobe Reader, а платные варианты Adobe Acrobat Professional или Adobe Acrobat Standard.
По второй части комментария. Нет, не всегда нелицензионный. Я поэтому и добавил слово «возможно». Т.е., ВОЗМОЖНО, используют нелицензионный, но я не могу утверждать это, лишь допуская такую возможность.
И свободных продуктов действительно много. Более того, иногда можно включать в стратегию возможность перехода к бесплатным продуктам по части приложений. Более того, считаю, что к софту надо относительно внимательно не только с точки зрения его покупки, но и с точки зрения оптимизации в плане перехода на свободное ПО. Если по фукнционалу сотруднику нужен простой текстовый редактор для использования в редких случаях, то зачем ему покупать MS Office для этого?
В отличие от выделенного сервера, позволяет легко мигрировать с площадки на площадку, легко масштабировать ресурсы под вашу нагрузку (процессорные мощности, память, дисковое пространство).
Сама суть услуги «Хостинг 1С» подразумевает предоставление сервиса и инфраструктуры заточенной под 1С и тяжелые базы данных (например выбор СХД- на SSD с большим показателем IOPS или обычных дисках), обеспечение прокидывания физических HASP ключей в «облаке» а так же обеспечение надежности и стабильности работы такого решения. Те (и это как правило) компании уже имеют ранее купленные программы 1С которую и переносят на наши площадки.
Мы можем предоставить и 1С в аренду, но это уже другая услуга (что уже массово представлена на рынке), но не настолько гибкое решение которое позволяет услуга «Хостинг 1С»
Вы совершенно правы что услуга подразумевает резервные площадки и кластеризацию, что обеспечивает стабильность работы и возможность миграции между площадками.
но в полемику вдаваться не будем, каждый выбирает то что ему удобнее…
Например я 100% гружу 1 ядро и сжираю 4ГБ ОЗУ — сколько мне это выйдет в час?
Тем, кто уже зарегистрировался, можно написать оргкомитету (http://sletadminov.ru/personal/3445/), они поменяют запрошенный размер в базе.