Привет, Хабр!
В этой статье мы расскажем, как построен процесс разработки платформы «1С:Предприятие», как мы работаем над обеспечением качества, и поделимся уроками, которые получили, создавая один из самых больших российских программных комплексов.


Люди и процессы


Над платформой трудятся несколько групп до 10 программистов в каждой, три четверти из которых пишут на C++, а остальные — на Java и JavaScript.
Каждая группа работает над отдельным направлением развития, например:
  • Средства разработки (конфигуратор)
  • Веб-клиент
  • Серверная инфраструктура и отказоустойчивый кластер
  • и т.д.

Всего групп более десятка. Отдельно есть группа обеспечения качества.
Конечно, на проекте такого размера (более 10 миллионов строк кода) речь об общем владении кода не идёт, удержать в голове такой объем невозможно. Мы стараемся двигаться к тому, чтобы обеспечить "фактор автобуса" в группе не ниже двух.
Мы стараемся выдерживать баланс между самостоятельностью команд, дающей гибкость и повышающей скорость разработки, и однородностью, позволяющей командам эффективно взаимодействовать между собой и внешним миром. Так, у нас общая система контроля версий, сервер сборки и таск-трекер (речь о них пойдёт ниже), а также стандарт кодирования на C++, шаблоны проектной документации, регламент обработки ошибок, пришедших от пользователей и некоторые другие аспекты. Правила, которые должны выполнять все команды, вырабатываются и принимаются общим решением руководителей групп.

С другой стороны, в практиках, которые направлены «вовнутрь», команды достаточно автономны. Например, инспекции кода сейчас применяются во всех командах (и существуют общие правила, определяющие обязательность прохождения ревью), но были внедрены в разное время и процесс построен по разным правилам.
То же самое касается организации процесса — кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде — специфика коробочного продукта накладывает свои ограничения. Например, замечательная практика демонстрации оказывается неприменимой в неизменном виде. Другие практики, например, роль Product Owner, имеют у нас свои аналоги. В качестве Product Owner по своему направлению обычно выступает руководитель группы. Помимо технического лидерства в команде, одной из самых главных его задач является определение дальнейших направлений развития. Процессы выработки стратегии и тактики развития платформы – это сложная и интересная тема, которой мы посвятим отдельную статью.

Работа над задачами


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

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

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

При начале работы над новой функцией для неё создаётся задача в таск-трекере. Трекер, кстати, написан на «1С:Предприятие» и бесхитростно называется «База задач». Для каждой задачи в таск-трекере хранится проектный документ — по сути, спецификация на задачу. Он состоит из трех главных частей:
  • Анализ проблемы и вариантов решения
  • Описание выбранного решения
  • Описания технических деталей реализации

Подготовка проектного документа может начинаться до реализации, а может стартовать и позже, если для задачи сначала делается какое-то исследование или прототип. В любом случае это итеративный процесс, не похожий на водопадную модель, развитие и уточнение проектного документа делается параллельно с реализацией. Главное, чтобы к моменту, когда задача была готова, проектный документ был утверждён во всех деталях. А таких деталей может быть множество, например:
  • Единство используемых терминов. Если в одном месте Платформы в похожей ситуации был использован термин «записать», то использование «сохранить» должно быть очень серьёзно оправданным
  • Единство подходов. Иногда ради упрощения изучения и единого опыта использования приходится повторять в новых задачах старые подходы, даже если очевидны их минусы
  • Совместимость. В тех случаях, когда старое поведение сохранять нельзя, нужно все равно подумать о совместимости. Часто бывает, что прикладные решения могут быть завязаны на ошибку и резкое изменение повлечёт неработоспособность на стороне конечных пользователей. Поэтому, мы часто оставляем старое поведение «в режиме совместимости». Существующие конфигурации, запущенные на новом релизе платформы будут использовать «режим совместимости» до тех пор, пока их разработчиком не будет принято сознательное решение о его отключении.

Кроме того, в проекте тезисно фиксируются обсуждения задачи, так, чтобы позднее можно было понять почему были приняты или отвергнуты те или иные варианты.
После того, как проект утверждён и разработчик реализовал новый функционал в ветке задачи (feature branch) в SVN (а при разработке новой IDE — в Git), задача проходит инспекцию кода и ручную проверку другими членами группы. Кроме того, на ветке задачи прогоняются автоматические тесты, о которых рассказывается ниже. На этом же этапе создаётся еще один технический документ – описание задачи, который предназначен для тестировщиков и технических писателей. В отличие от проекта документ не содержит технических деталей реализации, но зато структурирован так, что помогает быстро понять, какие разделы документации нужно дополнить, привносит ли новая функция несовместимые изменения и т.д.
Проверенная и исправленная задача вливается в основную ветку релиза и становится доступной группе тестирования.

Уроки и рецепты


  • Ценность проектного документа, как любой документации, не всегда бывает очевидна. Для нас она в следующем:
    • Во время проектирования помогает всем участникам быстро восстановить контекст обсуждения и быть уверенными, что принятые решения не будут забыты или искажены
    • Позже, в сомнительных ситуациях, когда мы не уверены в правильности поведения, проектный документ помогает вспомнить само решение и мотивацию, которая стояла за его принятием.
    • Проектный документ служит отправной точкой для пользовательской документации. Разработчику не нужно что-то писать с нуля или устно объяснять техническим писателям — уже есть готовая основа.
  • Всегда нужно описывать сценарии использования создаваемого функционала, причём не общими фразами, а чем подробнее, тем лучше. Если этого не делать, то могут получаться решения, которые будет использовать или неудобно, или невозможно, а причиной может служить какая-нибудь маленькая деталь. В Agile-разработке такие детали легко поправить на следующей итерации, а в нашем случае до пользователя исправление может дойти через годы (полный цикл: пока будет выпущена финальная версия платформы-> выпущены конфигурации, использующие нововведения -> будет собрана обратная связь от пользователей -> сделано исправление -> выпущена новая версия -> обновлены конфигурации с учётом исправления -> пользователь поставит себе новую версию конфигурации).
  • Ещё лучше, чем сценарии, помогает использование прототипа реальными пользователями (разработчиками конфигураций) до официального выпуска версии и фиксации поведения. Эта практика у нас только начинает широко использоваться, и почти во всех случаях приносила ценное знание. Часто это знание могло быть не связано с функциональными возможностями, а относилось к нефункциональным особенностям поведения (например, наличие логирования или лёгкость диагностики ошибок).
  • Точно так же нужно заранее определяться с критериями производительности и проверять их выполнение. Пока эти требования не добавили в чеклист при сдаче задачи, это делалось не всегда.


Обеспечение качества


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

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

Тесты


Когда речь заходит о механизмах обеспечения качества, сразу на ум приходят тесты. Мы, конечно, их тоже используем, причём в нескольких вариантах:

Unit-тесты

На C++ мы пишем unit-тесты. Как уже упоминалось в предыдущей статье, мы используем модифицированные варианты Google Test и Google Mock. Например, типичный тест, проверяющий экранирование символа амперсанда ("&") при записи JSON, может выглядеть вот так:
TEST(TestEscaping, EscapeAmpersand)
{
    // Arrange
    IFileExPtr file = create_instance<ITempFile>(SCOM_CLSIDOF(TempFile));
    JSONWriterSettings settings;
    settings.escapeAmpersand = true;
    settings.newLineSymbols = eJSONNewLineSymbolsNone;
    JSONStreamWriter::Ptr writer = create_json_writer(file, &settings);
    // Act
    writer->writeStartObject();
    writer->writePropertyName(L"_&_Prop");
    writer->writeStringValue(L"_&_Value");
    writer->writeEndObject();
    writer->close();
    // Assert
    std::wstring result = helpers::read_from_file(file);
    std::wstring expected = std::wstring(L"{\"_\\u0026_Prop\":\"_\\u0026_Value\"}");
    ASSERT_EQ(expected, result);
}


Интеграционные тесты

Следующий уровень тестирования — интеграционные тесты, написанные на языке «1С:Предприятие». Именно они образуют основную часть наших тестов. Типичный набор тестов представляет собой отдельную информационную базу, хранящуюся в *.dt файле. Инфраструктура тестов загружает эту базу и вызывает в ней заранее известный метод, который вызывает уже отдельные тесты, написанные разработчиками, и форматирует их результаты так, чтобы их могла интерпретировать инфраструктура CI (Continuous Integration).
&НаСервере
Процедура тест_Массив_Простой() Экспорт
     ИмяФайла = ПолучитьИмяВременногоФайла("json");
     ИмяЭталона = "эталон_Массив_Простой";
     Значение = Общие.ПолучитьПростойМассив();
   
     ЗаписьJSON = ПолучитьОткрытуюЗаписьJSON(ИмяФайла);  
   
     ЗаписатьJSON(ЗаписьJSON, Значение);
   
     ЗаписьJSON.Закрыть();
   
     Общие.СравнитьФайлСЭталоном(ИмяФайла, ИмяЭталона);
КонецПроцедуры

В данном случае, если результат записи разойдётся с эталоном, вылетит исключение, которое инфраструктура перехватит и интерпретирует как провал теста.

Наша система CI сама выполняет эти тесты под различные версии ОС и СУБД, включая 32- и 64-разрядные Windows и Linux, а из СУБД — MS SQL Server, Oracle, Postgress, IBM DB2, а также нашу собственную файловую базу.

Пользовательские тестовые системы

Третий и самый громоздкий вид тестов — это т.н. «Пользовательские тестовые системы». Они применяются тогда, когда проверяемый сценарий выходит за пределы одной базы на 1С, например, при тестировании взаимодействия с внешними системами через веб-сервисы. Для каждой группы тестов выделяется одна или несколько виртуальных машин, на каждую из которых устанавливается специальная программа-агент. В остальном разработчик теста имеет полную свободу, ограниченную только требованием выдавать результат в виде файла в формате Google Test, который может быть прочитан CI.

Например, для тестирования клиента SOAP веб-сервисов используется сервис, написанный на C#, а для проверки различных возможностей конфигуратора — объёмный фреймворк тестов, написанных на питоне.
Оборотной стороной такой свободы является необходимость ручной настройки тестов под каждую ОС, управление парком виртуальных машин и прочие накладные расходы. Поэтому, по мере развития наших интеграционных тестов (описанных в предыдущем разделе), мы планируем ограничивать использование пользовательских тестовых систем.

Упомянутые выше тесты пишут сами разработчики платформы, на С++ или создавая небольшие конфигурации (прикладные решения), заточенные под тестирование конкретного функционала. Это является необходимым условием отсутствия ошибок, но не достаточным, особенно в такой системе как платформа 1С: Предприятие, где большая часть возможностей не являются прикладными (используемыми пользователем напрямую), а служат основой для построения прикладных программ. Поэтому существует ещё один эшелон тестирования: автоматизированные и ручные сценарные тесты на реальных прикладных решениях. К этой же группе можно отнести и нагрузочные тесты. Это интересная и большая тема, про которую мы планируем отдельную статью.

При этом все виды тестов выполняются на CI. В качестве сервера непрерывной интеграции используется Jenkins. Вот как он выглядит на момент написания статьи:


Для каждой конфигурации сборки(Windows x86 и x64, Linux x86 и x64) заведены свои задачи по сборке, которые запускаются параллельно на разных машинах. Сборка одной конфигурации занимает длительное время — даже на мощном оборудовании компиляции и линковка больших объёмов C++ представляет непростую задачу. Кроме того, создание пакетов под Linux (deb и rpm), как оказалось, занимает сопоставимое с компиляцией время.
Поэтому в течение дня работает «укороченная сборка», которая проверяет компилируемость под Windows x86 и Linux x64 и выполняет минимальный набор тестов, а каждую ночь работает регулярная сборка, собирающая все конфигурации и прогоняющая все тесты. Каждая собранная и проверенная ночная сборка помечается тэгом, так чтобы разработчик, создавая ветку для задачи или вливая изменения из основной ветки был уверен, что работает с компилирующейся и работоспособной копией. Сейчас мы работаем над тем, чтобы регулярная сборка запускалась чаще и включала больше тестов. Конечная цель этой работы — обнаружение ошибки тестами (если её можно обнаружить тестами) в течение не более двух часов после коммита, чтобы найденная ошибка была исправлена до конца рабочего дня. Такое время реакции резко повышает эффективность: во-первых, самому разработчику не нужно восстанавливать контекст, с которым он работал во время привнесения ошибки, во-вторых, меньше вероятность, что ошибка заблокирует чью-нибудь ещё работу.

Статический и динамический анализ


Но не тестами едиными жив человек! Мы используем ещё и статический анализ кода, который доказал свою эффективность за многие годы. Раз в неделю находится как минимум одна ошибка, причём часто такая, которую не поймало бы поверхностное тестирование.
Мы используем три разных анализатора:
  • CppCheck
  • PVS-Studio
  • Встроенный в Microsoft Visual Studio

Все они работают немного по-разному, находят разные типы ошибок и нам нравится, как они дополняют друг друга.

Помимо статических средств мы еще проверяем поведение системы в runtime при помощи инструментов Address Sanitizer (часть проекта CLang) и Valgrind.
Эти два очень разных по принципу действия инструмента используются примерно для одного и того же — поиска ситуаций неправильной работы с памятью, например
  • обращений к неинициализированной памяти
  • обращений к освобождённой памяти
  • выходов за границы массива и т.д.

Несколько раз динамический анализ находил ошибки, которые до этого долго пытались расследовать вручную. Это послужило стимулом для организации автоматизированного периодического запуска некоторых групп тестов с включённым динамическим анализом. Постоянно использовать динамический анализ для всех групп тестов не позволяют ограничения производительности — при использовании Memory Sanitizer производительность снижается примерно в 3 раза, а при использовании Valgrind — на 1-2 порядка! Но даже их ограниченное использование дает неплохие результаты.

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


Помимо автоматических проверок, выполняемых машинами, мы стараемся встраивать обеспечение качества в ежедневный процесс разработки.
Наиболее широко применяемая практика для этого — Peer Code Review. Как показывает наш опыт, постоянные инспекции кода не столько отлавливают конкретные ошибки (хотя и это периодически происходит), сколько предотвращают их появление за счёт обеспечения более читаемого и хорошо организованного кода, т.е. обеспечивают качество «в долгую».
Другие цели преследует ручная проверка работы друг друга программистами внутри группы — оказывается, даже поверхностное тестирование не погруженным в задачу человеком помогает выявить ошибки на раннем этапе, ещё до того, как задача влита в ствол.

Eat your own dogfood


Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня. Каждый день эта конфигурация переводится на последнюю собранную на CI версию платформы, и все недочеты и недостатки сразу сказываются на их авторах.
Хочется подчеркнуть, что «База задач» — достаточно серьёзная информационная система, хранящая информацию о десятках тысяч задач и ошибок, а число пользователей превышает сотню. Это несравнимо с самыми крупными внедрениями 1С: Предприятие, но вполне сопоставимо с фирмой среднего размера. Конечно, не все механизмы можно проверить таким способом (например, никак не задействована бухгалтерская подсистема), но для того чтобы увеличить покрытие проверяемого функционала, есть договоренность, что разные группы разработчиков используют разные способы подключения, например кто-то использует Web-клиент, кто-то тонкий клиент на Windows, а кто-то на Linux. Кроме того, используется несколько экземпляров сервера базы задач, работающие в разных конфигурациях (разные версии, разные ОС и т.д.), которые синхронизируются между собой, используя входящие в платформу механизмы.
Помимо Базы задач есть и другие «подопытные» базы, но менее функциональные и менее нагруженные.

Выученные уроки


Развитие системы обеспечения качества будет продолжаться и дальше (да и вообще, вряд ли когда-нибудь можно поставить точку на этом пути), а сейчас мы готовы поделиться некоторыми выводами:
  • В таком большом и массово используемом продукте дешевле написать тест, чем не написать. Если в функциональности есть ошибка и она будет пропущена — затраты конечных пользователей, партнеров, службы поддержки и даже одного отдела разработки, связанные с воспроизведением, исправлением и последующей проверкой ошибки будут куда больше
  • Даже если написание автоматических тестов затруднительно, можно попросить разработчика подготовить формализованное описание ручных тестов. Прочитав его, можно будет найти лакуны в том, как разработчик проверял своё детище, а значит и потенциальные ошибки.
  • Создание инфраструктуры для CI и тестов — дело затратное и по финансам, и по времени. Особенно, если приходится это делать для уже зрелого проекта. Поэтому начинайте как можно раньше!


И ещё один вывод, который не следует прямо из статей, но послужит анонсом следующих: самое лучшее тестирование фреймворка — это тестирование построенных на нем прикладных приложений. Но о том, как мы тестируем Платформу с применением прикладных решений, таких как «1С:Бухгалтерия», мы расскажем в одной из следующих статей.

Комментарии (33)


  1. alexey-lustin
    21.12.2015 13:02
    +3

    Отлично. Просто отлично.


    1. Vetal4eg
      21.12.2015 13:57

      Я думал не доживу до этого дня (-:


    1. EvilBeaver
      21.12.2015 14:16

      alexey-lustin развейте мысль: отлично, что 1С становится более открытой или отлично, что они организуют свой процесс именно так, как организуют?


      1. alexey-lustin
        21.12.2015 14:35
        +1

        Раскрою. Разовью.

        1. во первых компания 1С сдержала своё обещания данное в первых статьях рассказать о том как работают над платформой в самой компании 1С — у меня были предположения, что социальную активность с хорошим контентом могут заблокировать. Точнее сдержал обещание PeterG
        2. во вторых — организация процесса: он строится как и положено… НО он строится как положено для С++ приложений. От него оторваны реальные сценарии использования.
        3. в третьих — я вижу свой блоки ассертов написанный на 1С. Держу скрещенные пальцы и надеюсь, что авторам платформы это надоест и они встроят это как объект платформы и назовут его Assertions


        1. leemuar
          30.12.2015 07:48

          Алексей, что именно должно надоесть авторам платформы?
          Если ассерты легко реализуются имеющимися средствами языка, зачем они нужны как встроенный объект? В чем преимущества встроенного объекта?


          1. alexey-lustin
            30.12.2015 10:56

            Ну как минимум в борьбе за скорость — это как с функцией РазложитьСтрокуВМассивПодстрок — её можно реализовать средствами языка, но быстрей было бы сделать обертку над методом Split().

            А как максимум в борьбе за стандартные подходы — мне сейчас известно о 4-ех публичных реализациях assertions на 1С, плюс я лично видел еще 5 непубличных. С одними и теми же проверками, только код разный.

            Просто язык 1С слегка не профильный для написания подобного. Оказалось что при написании библиотеки «Проверок», мы очень часто вынуждены реализовывать понятие рефлекции объекта 1С и анализировать стэк вызова, чтобы правильно выбросить исключение.


  1. vabue
    21.12.2015 13:39
    +1

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


  1. ComodoHacker
    21.12.2015 13:49
    +1

    Спасибо, познавательно.

    Написали бы про развитие языка. Какие планы, чего можно ожидать, чего нет. Правдивы ли слухи о возможной поддержке другого языка (типа JavaScript) в платформе?


  1. alexey-lustin
    21.12.2015 14:22

    Да кстати — пользуясь случае делюсь 2-умя гарантировано НЕ успешными сценариями поведения всех платформ от 8.3.3 до 8.3.7 (для ERP 2.1, УТ 11.2, БП 3.0, ЗУП 3.0 и Документооборота последних версий)

    Если уж мы говорим о том что тест лучше написать, чем не писать

    Первый «Идемпонентность поведения функции /DumpCfgSrc»

    &НаКлиенте
    //Когда я выгружаю конфигурацию ERP 2.1 в первый каталог Source1
    //@ЯВыгружаюКонфигурациюERP21ВПервыйКаталогSource1()
    Процедура ЯВыгружаюКонфигурациюERP21ВПервыйКаталогSource1() Экспорт
    	ЗапуститьКонфигураторВРежимеВыгрузкиКонфигурацииВФайлы("%ERPConnectionString%", "%WORKSPACE%\Temp\SourceERP1\")
    КонецПроцедуры
    
    &НаКлиенте
    //И я выгружаю конфигурацию ERP 2.1 во второй каталог Source2
    //@ЯВыгружаюКонфигурациюERP21ВоВторойКаталогSource2()
    Процедура ЯВыгружаюКонфигурациюERP21ВоВторойКаталогSource2() Экспорт
    	ЗапуститьКонфигураторВРежимеВыгрузкиКонфигурацииВФайлы("%ERPConnectionString%", "%WORKSPACE%\Temp\SourceERP2\")
    КонецПроцедуры
    
    &НаКлиенте
    //Тогда каталоги Source1 и Source2 должны быть идентичны по составу и контенту внутри файлов
    //@ТогдаКаталогиSource1ИSource2ДолжныБытьИдентичныПоСоставуИКонтентуВнутриФайлов()
    Процедура ТогдаКаталогиSource1ИSource2ДолжныБытьИдентичныПоСоставуИКонтентуВнутриФайлов() Экспорт
    	Vanessa.ПередатьНаПроверку("%WORKSPACE%\Temp\SourceERP1\","НеДолжныБытьРазличийМеждуКаталогами","%WORKSPACE%\Temp\SourceERP1\");
    КонецПроцедуры
    
    


    причина падения — перегенерация внутренних идентификаторов в СКД, Макетах печатных форм и т.д. Мы этот сценарий используем специально чтобы проверить когда проблема уйдет — а обходим через дополнительные фиксы получившейся выгрузки перед помещением в DCVS (режим 8.3.7 «выгрузка только измененных» также спасает, но там есть другие проблемы). То есть как выкрутиться мы знаем — но на всякий случай на каждой версии платформы прогоняем этот сценарий чтобы понять, когда починят.

    Второй — «Идемопентность поведения функции /LoadCfgFromSrc»

    тольке уже в формате Gherkin

    Сценарий: Идентичность двух конфигурации загруженных из одного каталога исходников

    Дано: Существует каталог ERP21Src с выгруженной последней версией ERP 2.1 через DumpCfgSrc

    Когда: Создается файл firstERP21.cf на основе каталога ERP21Src через LoadCfgSrc

    И Создается файл secondERP21.cf на основе каталога ERP21Src через LoadCfgSrc

    Тогда Отчёт о сравнении двух конфигураций должен не показывать различий между firstERP21.cf и secondERP21.cf



    Самое веселое, что если делать эти действия интерактивно через кнопки — то конфигурации будут идентичны. А не через командную строку — будут различия, причем в объектах типа Роль потеряются настройки прав доступа. Выкрутиться можно — загрузив конфигурацию повторно в уже загруженную.


    1. PeterG
      21.12.2015 14:30
      +1

      Алексей, пришли пожалуйста описание ошибки на v8@1c.ru.


      1. alexey-lustin
        21.12.2015 14:37
        +1

        Уже давно там — всегда вначале регистрируем как и положено. Здесь я поделился именно сценариями и кодом шагов воспроизведения.


    1. leemuar
      21.12.2015 20:14

      Алексей, спасибо что засабмитили это в саппорт! Мы делаем такие же тесты (только они записаны на powershell скриптах) с каждым новым релизом платформы. Мы делали большую видеозапись с демонстрацией тестов для саппорта 1С — а вы оказывается уже это сделали раньше.

      Вы смотрели новый релиз — 8.3.7.1790? В поздних версиях платформы различия внутренних идентификаторов исчезли (для наших конфигураций).
      Для наших же конфигураций именно на этой версии (8.3.7.1790) выгрузка впервые стала идемпотентной. Загрузка, к сожалению, все еще не работает корректно.

      Почему вы пишите про 8.3.3? Ведь возможность выгрузки всей конфигурации в файлы появилась только в 8.3.6.

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


      1. alexey-lustin
        21.12.2015 21:45

        Эх… Виноват. Я поделился нашими подходами для проверки сценариев. А подумали что я хочу обсудить особенности использования конкретной функциональности.

        Зря я написал что «падают» сценарии — тогда наши комментарии уйдут в обсуждение конкретных номеров тикетов. И кто-то подумает — что так правильно.

        Тогда отвечу коротко — по конкретным ошибкам: обсуждения в тикетах. ;-). Номера я лучше потом в личке скину.

        Поэтому коротко:

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

        Кстати — вы правы: именно с 8.3.4.437 идут наши эксперименты с выгрузкой в файлы 8.3.4.437 (проверили по истории репозитория).

        Что касается powershell — у нас так не получится: у нас очень много разработчиков используют клиентский Linux конфигуратор в режиме box'а с VNC. Поэтому мы создаём сценарии проверки на языке 1С.


        1. leemuar
          22.12.2015 08:19

          Алексей, спасибо! Наверно я написал так, что был неправильно понят. Я не работаю в 1С, номера тикетов мне ничего не скажут.

          Я работаю в компании, которая делает свою конфигурацию под внутренние нужды. Когда я прочитал в апреле на Зазеркалье о новой возможности выгрузки конфигурации в файлы — так же как и вы начал экспериментировать с внедрением DVCS в процесс разработки на 1С. И я провожу такие же тесты, как и вы, для каждого нового релиза платформы.

          Поэтому мои вопросы направлены только на то, чтобы обменяться опытом: поделиться своим и узнать как там у вас, чтобы не набить шишек


    1. ComodoHacker
      21.12.2015 21:07
      +1

      «Идемпотентность».


  1. artbear
    21.12.2015 17:24

    Спасибо, также не думал, что доживу :)

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

    Ничего не увидел о т.н. «сценарном» тестировании, добавленном в 8.3
    PeterG можешь прояснить, как используете этот механизм для повышения качества?


    1. PeterG
      22.12.2015 13:17

      Очень интересна внутренняя база тестирования (т.н. «интеграционные» тесты на языке 1С: Предприятия)
      ИМХО подобная ИБ была бы интересна многим разработчикам
      Вопрос — нет ли планов вывода этой ИБ в общую доступность?

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

      Ничего не увидел о т.н. «сценарном» тестировании, добавленном в 8.3

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


  1. 121212121
    21.12.2015 20:34

    «Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня.»

    Как я понял, почтовым клиентом 1с никто из разработчиков не пользуется.


    1. PeterG
      22.12.2015 12:30

      Внутри 1С мы (несколько сотен пользователей) используем 1С: Документооборот (в том числе и мобильного клиента Документооборота) для работы с почтой (внешней и внутренней), календарем, задачами, для коллективной работы с файлами и т.п.


  1. Cyrill
    21.12.2015 22:39
    +2

    Одно расскажите – почему построение оборотно-сальдовой ведомости падало при включённом аппаратном ускорении видео? :)


    1. tunegov
      22.12.2015 15:55
      +1

      Не все драйвера видеокарт одинаково полезны :-)
      Есть более курьезные случаи… У одного товарища установка мощной видео карты на сервере значительно ускоряло работу сервера 1С: Предприятия. Правда потом выяснилось, что он поймал трояна, который считал биткоины (конечно же на CPU, при отсутствии видео карты), но осадочек остался… :-)


  1. andreycha
    21.12.2015 23:13
    +1

    Выученные уроки

    Какой ужасный англицизм.


    1. RZimin
      22.12.2015 12:04
      +1

      Предлагаю «Былое и Думы»


      1. andreycha
        25.12.2015 00:14

        По-русски это обычно называется просто «Выводы».


  1. vladon
    23.12.2015 23:33

    А в чём заключается ваша модификация Google Test?


    1. PeterG
      24.12.2015 14:26

      Google Test модифицировался:
      1. Из-за особенностей STL, который использует платформа
      2. Для возможности тестирования dll и so компонентов из отдельного исполняемого файла — плеера тестов.


      1. vladon
        24.12.2015 14:28

        Ищете ли вы программистов (C++)?


        1. PeterG
          24.12.2015 14:33

          Да!
          Если есть заинтересованность — присылайте мне резюме на grip@1c.ru, я переправлю нашим кадровикам.


          1. vladon
            24.12.2015 14:49

            Отправил


            1. PeterG
              24.12.2015 15:24

              Получил, спасибо!


        1. VasiliyKudryavtsev
          24.12.2015 16:10

          Например, вот таких:
          hh.ru/vacancy/15265759
          hh.ru/vacancy/12526356


          1. vladon
            24.12.2015 16:14

            Спасибо


  1. VSOP_juDGe
    26.12.2015 17:20

    А у меня от последнего релиза 8.3.7 сложилось впечатление, что у вас как раз плохо с тестированием и стабильностью. Перешли на него с 8.2.18 прельстившись встроенной работой с json. Сначала клиент 1с рандомно падал с невнятной ошибкой sql, исправили, поигравшись с вариантами совместимости по совету от таких же бедолаг. Остались непонятные глюки с зависающими фоновыми заданиями, например при отправке писем, которые невозможно снять не перегрузив сервер. Иногда вылазят непонятные ошибки при динамическом обновлении, каждый раз заставляющие покрываться холодным потом. И скорость обновления конфигурации упала, к примеру не установив блокировку невозможно провести обновление, пока 1с телится после сброса пользователей, люди уже успевают снова заходить.
    В общем от последней 8.3 ощущение сырости, и много у кого на инфостарте такое же впечатление.