Пособие релиз инженера 1с и не только pdf
Есть такая вероятность, что скоро набрав в ya.ru запрос, можно вместо результата получить в ответ 404, ну т.е. или интернет запретят, ну или он не будет существовать в том виде в котором мы его знаем, ну там идиотские законы, отрубания от мира и прочая цензура. Все мы знаем, что толковая книга может стоить 3-4, а то и 5 тысяч руб. С учетом того, что читать желательно много, то это сумма легко может стать внушительной. Хорошо бы на этот случай иметь оффлайн версию нетленки. Какую литературу, фильмы и игры вы бы всегда хотели иметь всегда на "домашней полке" в виде золотого фонда? Предлагаю раскрашивать ответы голосовалкой, дабы люди могли бы пропускать не нужные им посты. Я под запрет интернета хочу массив дисков прикупить на 10сяток терабайт. Кто какой программой библиотекой пользуется для струтурирования и поиска файлов?
А еще скоро запретят свет, поэтому не забудь купить дизель-генератор. Только учти цена на дизель будет адовая, значит нужно искать генератор на дровах. И да пока валежник разрешили собирать, срочно бегом в лес заготавливать дрова, а то мало ли, может скоро и из дома запретят выходить
(1) может быть китайский вариант с полным отрубанием от внешних серверов и запретом торент протоколов. Вряд ли можно вылечить программными средствами отключеный рубильник.
(2)(3) Хорош. Если нечего сказать, просто проходи мимо.
(4) И тебя туда же. Особенно с такими закидонами, что книга должна стоить не меньше 5000. За что? За позолоченную обложку? Если конечно это не полное собрание сочинений В. И. Ленина. 55 томов - печку долго топить можно
*или интернет запретят, ну или он не будет существовать в том виде в котором мы его знаем, ну там идиотские законы, отрубания от мира и прочая цензура*
На мисте пахнуло либерастической куетой. Скороспелый ботяра детектед.
(6)
Искусство программирования. Том 1. Основные алгоритмы
1500 ₽
Искусство программирования. Том 2. Получисленные алгоритмы
1500 ₽
Искусство программирования. Том 3. Сортировка и поиск
1500 ₽
Только за 3 книги 4500 руб.
(7) (8) (9) (10) Странная реакция на вопрос, какую книгу вы бы хотели прочитать или иметь на книжной полке.
Тогда уже пусть тоже на полке стоит.
Дональд Кнут
Искусство программирования. Том 1. Основные алгоритмы
Искусство программирования. Том 2. Получисленные алгоритмы
Искусство программирования. Том 3. Сортировка и поиск
Ну триваиальное для списка и затравки.
(14) из Сабжа дословно " Какую литературу, фильмы и игры вы бы всегда хотели иметь всегда на "домашней полке" в виде золотого фонда? " - как это можно прочитать как то по другому?!
(15) Список не полный. Добавь туда:
Рабыня Изаура.
Просто Мария.
Богатые тоже плачут.
Санта-Барбара.
Спрут.
(17) Спасибо, нам очень важно ваше мнение. В следующий раз ставьте пожалуйста пункт голосования. Так будет проще искать по темам.
(19) посоветуйте пожалуйста книги по Психологии, как не хотеть задушить собеседника, который реально бесит.
От себя добавлю, что последнее читал
Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения
И еще мне купили книженцию на изучение
С учетом книг в электронном и не озоновских поступлений виде куплено всего книг где то на один миллион рублей
(0) Фильмы - нафиг, а не голдфонд. Не стоят они потраченного на них местаи усилий. Все стоящее регулярно по телику по каналам крутят разным в тч и по основным.
Книжки конечно надо бы, но зачем. только для разминки для ума. если зарабатываешь программингом на жизнь - то все нужное в компе есть. не будет инета, все будет в какомнить фидо на ббиэсях лежать.
(0) даже если отрубят, рунет всё-равно останется. А тебе какая разница, откуда пиратить крякнутую платформу 1с, с российской помойки или забугорной?
Как-то жил без интернета 20 лет. Получил образование, научился программировать. В библиотеку ходил. Ничего страшного не произойдёт при отключении интернета.
Можно будет вернуться к старому - FIDO, BBS. Маловероятно что это будет востребовано, т.к. технологии связи никуда не денутся, локальные сети не исчезнут, интернет с некоторыми ограничениями останется. Возможность заказать пиццу и книжку останется.
(0) ну жили мы в девяностые, когда инет был медленным и немного не по карману 90% людей. Тем не менее с литературой проблем особых не припомню, книги были доступны, сканировались, распространялись как в бумаге так и в электронном виде. Придется вспомнить, всего и делов.
(32) @ну жили мы в девяностые, когда инет был медленным и немного не по карману 90% людей. Тем не менее с литературой проблем особых не припомню@
Я учился в вузе в первой половине 90х. Интернета не было, в магазине нужных книг не было, в библиотеке - выдача только в читальный зал.
(24) Мои родители покупали при СССР еще, большую советскую энциклопедию. А это по тем временам коллекционная вещь и стоила 600 советских рублей. Вы говорили, что математику любили. Накидайте пожалуйста интересных книг по Математике, логике, шахматам, устному счету. Сам недавно, накачал себе математика 6-11 класс на повторение. Господи какое же оно убогое все. Один учитель математики сказал, когда 2 года открывают скобки, то ум заходит за разум. Попытка научить всему, всех, приводит к тому, что потом никто ничего не знает. Ни сообразительные, он к тому моменту уже все забудут, пока идиотов научат. Ни идиоты, они не способны ничего выучить.
(28) Ну ок. Читай как Фильмы и Музыка. Вряд ли the beatls крутят постоянно по телеку.
(30) В заморском интернете висят наши сервера с контентом и все сайты запрещены. Так что при отключении западного интернета накернится и весь наш. Даже если не отключат, почему бы дома не иметь золотой коллекции, мировой музыки и литературы? Это что плохо иметь в хорошем качестве любимые фильмы и музыку? Не тратить кучу времени на поиск книг, а иметь это все в собственной библиотеке.
Я наверное себе в коллекцию всю классику скачаю типа
Вивальди,
Бетховена,
Баха,
Моцарта,
все 1960е как целыми альбомами так и хиты.
The beatls
Doors,
Blonde,
shangrilass,
Dixi caps,
animals.
(43) Если бы я родился
Если б я родился в Северной Корее
Я наверно стал бы милиционером,
Может велорикшей, может Кимерсеном,
Но скорей всего бы стал милиционером
Если б я родился принцем в Монте-Карло
Я б окончил школу с золотой медалью.
После института стал бы баккалавром,
А после смерти папы - главою государства.
Припев не формат
Если б я родился за полярным кругом
Я б наверно умер от холода и скуки.
Может быть не сразу, может быть чуть позже,
Но все равно бы умер от холода и скуки.
Если б я родился в Великобритании
Я играл бы песни в каком-нибудь ансамбле.
Может быть на дудке, может быть на гитаре
Я играл бы песни в каком-нибудь ансамбле.
Крематорий, пожалуй единственное из русскоязычного, что я бы в коллекции оставил.
(38) Жесть какая то. По 5-6 книг в месяц.
Тут 3 варианта. Либо это все не для себя, а для сотрудников отдела, либо ты их не читаешь, либо ты конченный библиофил и читаешь по ночам.
(42) даже если обрубят заморский тырнет, это произойдёт не внезапно. У владельцев ресурсов будет время, чтобы перетащить свои сайты на российские сервера
(42) Зачем заранее копировать? Наверняка у кого-нибудь это будет. Проблема копирования была лет 30 назад, когда всё было в аналоге, на кассетах. 10-я копия была уже никакой.
Сейчас, в век цифровых технологий подобная проблема сохраняется у некоторых обладателей смартфонов, которые копируют фото и видео с экрана компьютера. Но всё равно заполучить оригинал проще.
(48) +100500 автор просто хочет похвастаться своим "золотым фондом"
При отключении инета должна быть в наличии вот эта книга
http://v8.1c.ru/metod/books/book.jsp?id=401 все остальное по вкусу. Кому-то хочется читать донцову, кому-то "Управление рисками".
(46)(47) Даже, если не отрубят, то почему не поделиться ссылками на интересный контент с коллегами?
(49) у меня такая с 2005 года есть. Честно говоря, открывал ее мало, быстрее в интернете найти. Мне пока хвастаться нечем, я созданием библиотеки только вчера озаботился, хотя давно хотел систематизировать имеющиеся книги. Иногда час потратишь разыскивая литературу, а потом оказывается она у тебя уже есть.
(35) я во второй. Были в продаже книжки, другой вопрос что, конечно, недешево это было для студентов. Но покупали, что ж делать. Часто дарили книги друзьям на ДР - и подарок сделал, и потом взять почитать можно, очень удобно :) В библиотеках кое-что было, соответственно брались книжки на ночной абонемент и сканировались, году в 97 у меня уже был купленный за кучу денег планшетный сканер.
(34) Мань, коллекционирование одна из разновидностей фетишизма, что является психическим отклонением. Так, что покупать и коллекционировать предметы - это как раз не нормально. Хотя я любую чужую слабость уважаю, я предпочитаю коллекционировать информацию. Ведь мы живем в век информационных технологий, и истинную ценность представляет только информация.
В современном IT мире вокруг различных практик, объединенных общим названием DevOps, возникло достаточно много хайпа. Стоит отметить, что достаточно обоснованного, т.к. применение данных подходов во многих случаях позволяет не то что увеличить производительность команды или скорость выпуска продукта, а просто сделать это возможным в принципе. Для некоторых компаний и команд DevOps трансформация стала просто спасением.
Отдельные практики DevOps дошли сейчас даже для 1С. В частности – много внимания мы уделяем сейчас CI/CD. Но давайте разберёмся – что реально может дать CI/CD команде разработки 1С. С точки зрения «Best Practice», конечно, этим заниматься надо, но откуда берётся эффективность?
Откуда взялось CI/CD? Какие задачи при помощи них решали?
Для начала несколько лирическое отступление на тему «откуда пошло CI/CD». Очевидно, что CI/CD пришли к нам из других направлений разработки, в частности из Web команд, как и множество других инноваций. Как работают Web команды? Примерно вот так:
Суть в том, что одну фичу может делать 2-3 человека. Как минимум принято разделять Frontedn и Backend разработчиков. В нормальной команде существует ещё DBA или разработчик БД, отдельный дизайнер и отдельный верстальщик, не говоря уже о наличии QA как такового. И где тут проблемы?
Это называется «Merge» и чем то напоминает процесс «Сравнения и объединения конфигурации». Ну не оно ли:
Вспоминаем, как мы очень жутко не любим сравнение и объединение конфигураций и пытаемся его всячески избегать. А вот Web разработчики не избегают, таким образом их «история хранилища» выглядит как то так:
Как и у нас они на эту тему тома пишут
Сколько при таком подходе будет выпускаться готовый продукт? Да сколько угодно! Притом, без преувеличений, даже просто получить рабочую версию системы в большинстве случаев бывает проблемой. А если система состоит из микросервисов, то вообще вскоре «заблудитесь» что где работает а что нет? В случае микросервисной архитектуры традиционные и привычные подходы вообще скорее всего являются невозможными? В этом случае концепция CI/CD кажется просто спасением – после каждого коммита нужно собирать систему целиком, и проводить полное или хотя бы базовое тестирование всего функционала. Таким образом, практически исключаются большие «мерджи», которые ломают всю систему, и она всегда находится в некотором стабильном состоянии. Соответственно – главным назначением практики CI/CD – является решение проблемы больших мёрджей и их последствий, а также упрощение выпуска релиза системы.
А что в 1С?
А в 1С всё просто: в базовом варианте в команде разработки 1С нет возможности изменять один и тот же кусок кода. «Захватить в хранилище» и до свидания. Хранилище 1С не поддерживает ветвлений, это делает процесс разработки предельно линейным, что в целом эффективно для небольших команд. Но при этом мы теряем все преимущества процесса параллельной разработки. Соответственно в большой команде разработки 1С иногда можно наблюдать примерно такой процесс:
Процесс работы с разными объектами конфигурации строго последователен, зато нет никаких коллизий, мерджей, веток, их слияния… Для небольших команд это, пожалуй, наиболее правильный вариант, для больших жутко неэффективно. По аналогии можно сравнить как табличные и построчные блокировки. Если в базе работает 2-3 человека – нет смысл поддерживать всю инфраструктуру для построчных блокировок – табличные будут эффективнее, но если в базе человек 50 и более, то с табличными блокировками вы просто всё время будете «в режиме ожидания».
Конечно, «опытные 1С-ники» меня сейчас поправят. Как так, а у нас – параллельная разработка на 1С реализована:
Enterprise Development Tools – пожалуй, самое обсуждаемое среди разработчиков нововведение в платформе 1С. Одним из основных назначений его появления должна быть нормальная параллельная работа. В случае с EDT система контроля версий – это GIT. С конфигурацией вы работаете как с набором файлов, ничего нигде не лочите. Можете создать себе ветку, можете провести слияние веток. При этом слияние учитывает, естественно, специфику 1С. У вас появляется возможность сделать нормальный precommit, написать своё расширение и многое другое. Но на данный момент его использование в реальной разработке весьма сомнительно. EDT несёт в себе очень много недостатков:
1) Очень прожорливо, ну просто очень. Вот такие показатели у меня отображаются в диспетчере задач при нормальной работе:
Даже при современном уровне мощностей далеко не каждый может себе позволить такую расточительность
2) Не поддерживает и никогда не будет поддерживать обычные формы. А сейчас это очень большой пласт прикладных решений, особенно тех в которых ещё ведётся разработка
3) Нет нормальной автоподстановки. В Eclipse её и для Java то нормальной нет, а для 1С не понятно появится ли. До возможностей конфигуратора со встроенным Снегопат-ом, соответственно, ещё очень далеко
4) Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM.
5) Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим.
6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
Таким образом, если говорить о процессе CI – когда постоянно происходит сборка кода, его проверка, автоматическое слияние - для 1С в настоящее время едва ли актуален.
Хотелось бы сказать что-нибудь хорошее про процесс CD – на Production надо выкатывать как можно быстрее, но тут тоже есть ограничения платформы. За многие годы развития мы так и не ушли до конца от монопольного режима при обновлении. Какое уж тут CD. Опытные 1С-ники, конечно, скажут, что всё решаемо. Делается РИБ и переключение, или обновляется вручную структура СУБД и текущая конфигурация… Но это очень далеко от принципов CD, а наоборот, требует тщательного планирования и ручного контроля.
Кроме того, базовые практики CI подразумевают покрытие тестами всего кода. Но на проектах 1С большинство кода никак не относится к вашей команде разработки. А автоматизированное развертывание и покрытие его тестами займёт чаще всего больше времени, чем сам проект.
Теперь давайте посмотрим, как построен стандартный процесс CI где-нибудь в Web разработке:
Происходит примерно следующее:
1) Вы делаете commit
2) По Webhook запускается CI процесс
3) Разворачивается docker контейнер тестовой среды (она же небольшая – некий объём кода и начальная БД)
4) Выполняются unit тесты (помним что весь код в вашем приложении написала ваша команда и она же покрыла его тестами)
5) Выполняется проверка кода
6) Вы получаете красный или зелёный свет.
В общем, поразмыслив над всем этим, я по традиции обратился «к старшим братьям», или к SAP. Потому что что-то подсказывает, что у них точно такие же проблемы.
И как же дела c CI/CD у SAP?
И первое, на что наткнулся на просторах интернета:
Потом на статью, в которой человек жалуется, как в SAP всё плохо с DevOps Так что же теперь, забить на весь этот DevOps?
Разберём плюсы и минусы применения практик CI/CD с учетом ограничения технологической платформы 1С:Предприятие.
5) Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим.
6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
Верно сказано. EDT это мертворожденный ребенок, хоть и более желанный чем старенький конфигуратор.
Кроме того EDT не работает с платформами ниже 8.3.8.
(32)
А может быть, на примере с EDT нужно сделать вывод, что 1С не будет тем же, что и другие языки? 1С всегда отличался, и будет отличаться. Эти отличия, конечно, несут и минусы. Но эти же отличия несут и фундаментальные плюсы, благодаря которым платформа и заняла свой рынок и продолжает его отвоёвывать у прямых зарубежных конкурентов. Медленно, но верно. Годы идут, но 1С не теряет актуальности. Хотя и 10 лет назад говорили, что "1С уже фсё", и 15 лет назад.
А меж тем, зарплаты разработчиков 1с то же растут. Это происходит естественным путём, благодаря здоровой конкуренции на рынке. И это говорит о том, что 1с на этом рынке конкурентоспособна.
Невозможность распараллеливания работы над одним объектом привело к тому, что 1Сник - "и на дуде дудец, и на гитаре трындец", в то время как веб-разработчики более подвержены профдеформации, и через 2-3 года работы с одним фреймверком на одном направлении атрофируют другие навыки разработки. Да, мы не станем "специалистом по правой ноздре", так чтобы знать все, но с другой стороны мы можем (что чаще всего и происходит) самостоятельно разрабатывать, внедрять поддерживать всю учетную систему, а специализация конкретного навыка (например знание принципов работы с внешними источниками данных) в принципе может и не всегда нужна, или быть достигнута при помощи коллег/формумов/рабочего выходного.
За статью спасибо.
Ссылки не совсем корректные - добавлен лишний символ, который переводит на страницу 404.
Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом
4) Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM.
Какой то вброс негативной информации, без пруфов.
Возможно java проигрывает с++ в качестве числодробилки в один поток, но хадуп, спарк, кассандра, кафка, зукипер, дженкинс что вы о них скажете?
(7) полагаю, Олег имел в виду именно GUI-приложения Java. Я видел только одно нормальное - IDEA от Jenbrains. Но там кастомный, вылизанный GUI. Все "типовые" библиотеки для интерфейсов под Java - адское говнище (в данном случае - медицински точный, выверенный термин, а не захлестнувшие эмоции)
к строке запуска и jar-ник с темой.
Просто на java никто не любит писать гуешные приложения, дa и SWT( гуи эклипса) - совсем не стандартная.
з.ы. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам.
Ну просто это не цель для Java разработчиков.. Java это таки энтерпрайз, и основа для web приложений. Для других целей есть другие нгормальные инструменты.
(9) Ну не только GUI. В высоконагруженных системах JVM тоже лишняя роскошь. Но интерфейс это именно то как ты сказал :)
Туфта. Это пишет человек, не пробовавший разветвленную технологию в работе.
Никаких затрат, и никакой сложности. А уж мёрж, благодаря технологии файлов поставок, прост как две копейки.
(10) Если бы не пробовавший. Не было бы этой статьи.
" А уж мёрж, благодаря технологии файлов поставок, прост как две копейки."
А это пишет человек который не видел что такое простой мёрж
(20) Ой да ладно.
Поставка - Обновить - Только дважды измененные - Выполнить.
(22) эээ а ссылку выше читали? "порядок создания хранилища", "порядок обновления хранилища", или вообще не представляете о чём речь?
(23) Я эту методологию не просто читал, я ее использую на практике.
Поэтому сразу видно кто "просто читал", а кто использовал.
(26) Скорее всего Олега попросили внедрить инженерные практики - но это вызвало у него боль отраженную в статье. Он просто не дошел до применения инструментов - поэтому и ошибся упоминая v8unpack ;-) который уже давно не нужен.
(35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.
(35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.
Баян.
А теперь трудозатраты на "добавить реквизит" по СППР-Workflow :). А самое интересное - трудозатраты на "слить ветку". Ну не говоря ещё про "протестировать изменения", сделать ветку от ветки.
Для компаний которые не выполняют проектирование и хреначат все сразу в прод - наверное чтобы "добавить реквизит" это все не нужно. Для остальных - надо делать техпроекты.
Трудозатраты на атомарные операции - выше безусловно. Экономия времени за счет продумывания и предварительного проектирования покрывает этот расход. Надо к СППР-Workflow относится не как к процессу "что-то изменить к конфигурации", а как к процессу "что-то изменить в продукте".
Чтобы "протестировать изменения" достаточно запустить CI на ветке техпроекта) Обычно настройка этого не занимает времени вообще.
а вот это из другой оперы. из той где есть бэклог, нету техпроектов. есть таски и они выполняются, выполняютя быстро.
При определенныхусловиях это может быть обоснованно, но в случае СППР-Workflow "ТехПроект" это именно то что называют "ТехПроектами" 1С-франчайзи. Про CI и какой-либо Workflow 1С в этом случае не думали.
Про него, слава богу, подумали хотя бы при разработке EDT
(35) Вот если на пальцах объяснять, то это работает так:
Есть git - но это только хранилище. Когда давно в бородатых годах был придуман git-flow со всякими удобными ветвлюшками - как процесс разработки.
Сейчас чаще на практике используют gitlab-flow который лучше ложится на CI/CD.
В gitflow есть понятие - support branch (не все про него знают) - это стабильная ветка проекта, первая стабильная - называется master - остальные по примеру support-v1.2.3. Т.е. та в которой исправляются ошибки даже после выпуска новой мажорной версии. В gitlab-flow это называется stable branch. В СППР это называется - хранилище версии проекта.
Ответвления для разработки новой функциональности features-* в СППР являются техническими проектомами. Они позволяет полностью собирать ошибки и идеи (в gitlab issues) которые планируется реализовать, плюс процесс контроля согласования, исполнения, тестирования и конечно же ответвления и слияния с хранилищем основной версии проекта (master в мире git).
Вот в карточке технического проекта и есть функции создания хранилища для этого техпроекта - т.е. ответвления от мастера или другой стабильной ветки. И слияния в нее обратно.
(39) Да я видел как это работает. В production хотел бы конечно посмотреть. я развернул ветку для ERP, проверил слияние. проверил создание тех ветки, накатывание изменений на тестовую базу. Посчитал затраченное время. Ну это очень убого и долго, чесслово.
Методическое пособие релиз-инженера 1С и не только
Книга посвящена вопросу создания автоматизированного процесса управления релизным циклом решений на базе платформы 1С:Предприятие 8.
В книгу включены материалы, описывающие современные практики управления релизным циклом, инструментарий автоматизации выпуска релизов, проверки качества кода. Также подробно рассматриваются вопросы виртуализации и контейнеризации инструментов релиз-инженеров.
Прочитав книгу, вы узнаете:
Как сократить время выпуска версии продукта
Как использовать виртуальные и контейнерные окружения, организовывать стенды и "песочницы"
Как управлять версиями кода
Как автоматизировать тестирование
Как автоматизировать создание документации по продукту
И многое другое.
Книга рассчитана на разработчиков 1С, занимающихся выпуском и развертыванием решений в рабочих контурах, а также технических руководителей команд, ответственных за улучшение качества кода, решений, создаваемых на платформе "1С:Предприятие 8".
Рассматриваемые в книге инструменты преимущественно следуют философии открытого программного обеспечения (Open Source).
Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.
В это время я работал в одной уважаемой компании и по делам службы познакомился с одним классным программистом и вообще хорошим человеком Андреем Щегловым (Привет Андрей!) и как =-то за разговором он у меня спросил, слышал ли я что-нибудь об OneScript и языке сценариев Gherkin. На что и получил ответ что нет, не слышал. Естественно, вечернее гугление/яндексение и бессонная ночь привела на мысль что вот он — мир неизведанного. Но идея о том, что это может стать темой дипломной работы пока не зарождалась. Рутинный круг обязанностей составлял обычную работу в Конфигураторе 1С по-задачно, как вы понимаете с ручным тестированием и не позволял полностью погрузиться в новый подход в мире 1С.
Незнакомые понятия
Первая трудность с чем я столкнулся, это неимоверное количество различных терминологий и инструментов, о которых вообще не слышал — так как я в тот момент был «типичным одинэсником» (в этот момент начинается холивар…) Особо не владея никакими другими языками программирования, и к тому же методологии большого IT для меня были абсолютно не знакомыми, мне приходилось прыгать с темы на тему, чтобы хоть как-то наполнить свой глоссарий.
Практически в этот же момент я (мы – и мои коллеги) столкнулись с довольно специфичной проблемой. Приняли программный модуль от подрядчика, проверили на копии. Вроде все работает. Но так как работы было очень много, то подписали акт выполненных работ и закинули в продуктив. Все было хорошо в течении полугода, пока данных в этой подсистеме не превысило допустимого. И начали происходить очень странные вещи. Проведение документа из модуля стало происходить по 5-10 минут, появились куча ошибок ну и.т.п. Просмотр программного кода привел в ужас (не спрашивайте почему это не сделали раньше при приемке…). Количество вложенных циклов было просто за гранью разумного. Единственный запрос в четвертом цикле и обращение через 4 точки были мелочами, перебор всех предыдущих документов для заполнения текущего документа, 10-ти кратный копипаст одного и того же блока и много еще чего.
Дублирование полей в макете:
Причем для заполнения этих полей, 14-ти кратный кописпаст.
И пока переменная ФФ не достигнет 15:
Ну и еще куча других не менее уникальных произведений искусства.
Вдруг я вспомнил, что для OneScript есть простенькая библиотека для расчета "цикломатичности" модуля(1) (сложности модуля или метода). Нашел, рассчитал. Получил значение 163 единицы, при допустимом значении не более 10. И пришел к выводу, что приемочное тестирование программного кода должно быть обязательно и оно должно быть автоматическим и непрерывным. Тогда я узнал о Continuous Inspection — причем как оказалось еще в 2006 году компания IBM сделала(2) публикацию на эту тему.
Дальше больше. Наверное, многие работающие в крупных компаниях встречались с проблемой разворачивания копии рабочей базы на локальной машине разработчика. Когда эта база весит 5-10 гбт – это не проблема, а когда она только в бэкапе весит почти терабайт то это уже серьезно. В итоге для того, чтобы развернуть у себя свежую копию тратилось по 5-6 часов рабочего времени. Когда мне это надоело я начал пользоваться очень хорошим инструментом 1C-Deploy-and-CopyDB (Антон спасибо!) Тогда я понял, что автоматизация – это классно.
Дальше были другие задачи, например, регулярное обновление основной и распределенной базы из хранилища ночью, тестирование форм, сценарные тесты и.т.д. Что-то было из этого реализовано, а что-то нет.
Но все это нужно было только мне. При поиске единомышленников в своем городе практически потерпел фиаско. Их нет. Хотя жутко странно, так как проблемы типичные. В этот момент я уже знал, что хочу написать свою дипломную работу именно по этой теме. Но что писать – не знал. Поэтому пришлось подключиться к сообществу в качестве уже не просто читающего, а как минимум пишущего и задающего вопросы. Основными местами, где можно задавать вопросы оказались
Ну и как средство быстрой связи — профильные группы в Gitter
Начался сбор материала. Волею судеб мне удалось мне связаться на форуме XDD с Алексеем Лустиным alexey-lustin (Привет Алексей!) и рассказать про мою идею диплома. На что, с удивлением услышал, одобрительный отзыв и даже приглашение пройти в компании «Серебряная Пуля» преддипломную практику. Это была уже победа. В течении нескольких часов мы придумывали тему и содержание диплома. Ставили задачи на практические работы. Получил руководителя дипломного проекта от компании — Артур Аюханов (Артур привет!) Как юный падаван получил доступ к видеокурсу релиз-инженера и возможности неограниченно доставать Никиту Грызлова (Привет Никита!) своими вопросами, за что ему очень признателен.
В итоге:
Тема диплома — «Автоматизированное управление жизненным циклом информационных систем — системная и программная инженерия решений на платформе 1С: Предприятие в условиях непрерывного улучшения качества процесса производства».
Цель выпускной квалификационной работы (ВКР) — выявление взаимосвязи программных инструментов и описание бизнес-процесса работы контура DevOps в области 1С.
Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0, а в качестве практического объекта было выбрано построение контура непрерывной интеграции для нового прикладного решения, которое мы разработали – личный кабинет покупателя. Для этого был развернут сервер исходных кодов GitLab и сборочный контур Jenkins. Прогон тестов осуществлялся на выделенном сервере (Windows Slave). Выгрузка конфигурации из хранилища 1С осуществлялась посредством библиотеки Gitsync, редакция 3.0
(в настоящий момент размещен в ветке develop) уже с наработками Алексея Хорева (Леха привет!) с периодичностью 30 минут в ветку develop. Причиной выбора именно этой версии была возможность подключения к хранилищу через протокол tcp, который, к сожалению, не поддерживал на тот момент типовой GitSync 2.x. Если в GitLab фиксировались изменения, то автоматически запускался прогон контура непрерывной интеграции.
Так как бюджет всего мероприятия был нулевым, и возможности построить полноценную проверку качества программного кода без покупки модуля для SonarQube было невозможно, то в качестве упрощенного решения использовалась типовая проверка синтаксиса 1С. Хотя разовые выгрузки все-таки были сделаны, а результаты были получены и проанализированы. Также были использованы дополнительные проверки на цикломатичность и на наличие повторно используемого кода.
На этапе тестирования функционала были задействованы 2 фреймворка Vanessa-Behavior и XUnitFor1C в их объединенном варианте под названием Vanessa Automation Driven Development (Vanessa ADD). Первый использовался для запуска тестировании ожидаемого поведения, вторым осуществлялась проверка открытия форм (дымовое тестирование). Результатом прохождения контура непрерывной интеграции были автоматически сгенерированные отчеты.
По результатам тестирования, релиз – инженер принимал решение о слиянии ветки develop и master, и запускал (уже вручную) третью задачу – публикацию изменений в продуктивную базу. Продуктивная база не подключена к хранилищу и полностью закрыта от ручных изменений. Обновление осуществляется только через поставку, причем в автоматическом режиме.
Для описания бизнес-процесса работы контура была сформирована диаграмма IDEF0 состоящая из 4 последовательных блоков, формирующих прохождение контура. Ошибка возникающая при прохождении любого из этапов прерывает сборочный процесс с оповещением релиз-инженера и передает управление на 5 блок сборочного процесса, где и формируются отчеты в в формате ALLURE, JUNIT и конечно cucumber.json.
Описание модели IDEF0
Процесс «Выгрузка исходников в GIT»
Обязательным условием существования контура является наличие файлов исходного текста. С версии платформы 8.3.6 компания 1С предоставила возможность выгрузки исходных кодов конфигурации в файлы. Следует учесть, что данный процесс может иметь несколько вариантов исполнения, зависящих от специфики разработки в IT отделе. В текущем варианте для упрощения процесса перехода сотрудников к новой методике была выполнена интеграция с текущим процессом разработки через хранилище конфигурации и используя конфигуратор 1С.
На этапе выполнения процесса «Выгрузка исходников в GIT» будет произведено создание файловой, служебной информационной базы 1С; осуществлено ее подключение к хранилищу конфигурации под служебной учетной записью; получены все изменения на текущий момент времени (или последнему коммиту в хранилище); произведена выгрузка исходников в сборочную директорию; сделан коммит в систему хранения версий GIT; изменения отправляются на сервер исходных кодов GitLab
Процесс «Тестирование качества исходного кода»
На момент старта данного процесса, исходный код хранится в репозитарии GitLab. С помощью управляющего (сборочного) скрипта производится получение его в сборочную директорию. Средствами платформы 1С: Предприятие, на основании этих исходных кодов разворачивается служебная информационная база. Производится анализ ошибок средствами платформы. В случае, если при выполнении анализа будут обнаружены ошибки программного кода, не позволяющие собрать конфигурацию, то процесс прервется. Цель данного шага – исключение потерь времени на анализ программного кода неработоспособной конфигурации.
После проверки на ошибки запускается подсчет цикломатической сложности программного кода. Увеличение этого коэффициента существенно отражается на отладке и анализе программного кода. Максимально допустимое значение 10. При превышении вызывается исключение, и код возвращается на доработку.
Заключительным шагом анализа качества программного кода является проверка на соответствие стандартов разработки. Для этих целей в предложенной схеме используется сервис SonarQube и разработанным для него модулем поддержки синтаксиса 1С от компании «Серебряная пуля». По результатам анализа система рассчитывает значение технического долга для каждого сотрудника, разместившего программный код.
Процесс «Тестирование функционала»
В процессе разработки могут происходить ситуации, что новый функционал может нарушить работу уже существующих подсистем. Это может проявляться как формировании исключений, так и выводе не ожидаемого результата. Для этих целей производится тестирование ожидаемого поведения системы.
Для данного контура применимо несколько методов разработки и тестирования: TDD (Test Driven Development) и BDD (Behaviour Driven Development)
На момент написания ВКР, для выполнения тестов по Методике BDD использовался фреймворк Vanessa-bahavior, для TDD – XunitFor1C. В настоящий момент они объединены под одним продуктом Vanessa-ADD. Поддержка старых продуктов разработчиком прекращена. Результаты тестирования выводятся в файлы отчетов Yandex Allure и Xunit.
Процесс «Сборка поставки»
В данном процессе происходит окончательная сборка поставки конфигурации для развертывания в целевой системе. Проверенный исходный код находится в ветке develop репозитария исходных кодов GitLab. Для формирования поставки необходимо, что бы изменения из ветки develop появились в ветке master. Это действие может происходить как вручную, так и автоматически и регламентируются требованиями IT подразделения использующего контур CI/CD. После слияния веток запускается процесс сборки готовой поставки. Для этого опять в сборочной директории, на основании существующих исходников, создается служебная информационная база, и затем, средствами платформы 1С: Предприятие формируется поставка конфигурации и архивируется. Поставка конфигурации является финальным продуктом сборочного процесса и поставляется заказчику по установленным каналам связи или же устанавливается непосредственно в продуктивную информационную систему.
Процесс «Публикация результатов»
При выполнении этапов процесса, инструменты тестирования создают как побочный продукт файлы отчета в определенных форматах. Задача данного процесса произвести группировку, преобразование и публикацию для удобства анализа данных. В случае формирования исключения на каком-то этапе сборки и при наличии нужной настройки система должна автоматически уведомить администратора контура о наличии проблем. Этот этап выполняется в постобработке сборочного процесса и должен выполниться вне зависимости от результатов предыдущих процессов.
Результатами моего проекта стала защита ВКР в конце мая этого года с результатом «отлично». Дополнительно, была актуализирована методическая информация по формированию контура.
Общие выводы:
- Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня. Этот период временный, и как правило производительность возвращается к первоначальным значениям через три – четыре месяца эксплуатации. Снижение производительности связанно прежде всего, с тем, что разработчику приходится привыкать к новым требованиям разработки: написанию сценариев, тестов, формированию технической документации.
- Существенно повысилось стабильность продуктивной информационной системы, за счет тестирования программного кода. Гарантированная работа критически важных подсистем обеспечена покрытием сценарными тестами. За счет этого снизились риски компании на критически важном направлении — оперативное взаимодействие с клиентами.
- Исключение динамических исправлений на продуктивной информационной базе позволило более конструктивно планировать разработку и исключить попадание программного кода в обход контура тестирования.
- Снижение трудозатрат на сервисное обслуживание информационной базы, за счет автоматизации сборочного контура.
- Использование обратной связи через Slack позволило в оперативном режиме контролировать и исправлять проблемы жизненного цикла системы. По отзывам команды, использование месенджера, удобнее почтовой рассылки (хотя она тоже присутствует).
- Использование автоматизированной проверки программного кода (Continuous Inspection) на соответствие стандартам разработки (SonarQube) вынуждает разработчиков самостоятельно повышать компетенцию, а исправление выявленного технического долга непосредственно при разработке программного модуля происходит гораздо быстрее, так как не надо тратить время на восстановление контекста задачи.
- Включение функционала авто-документации и генерации видео-инструкций позволяют снизить количество обращений пользователей.
- В ходе выполнения проекта был сформирован бизнес-процесс, описывающий жизненный цикл разработки и тестирования прикладных решений 1С, который в свою очередь повлиял на формирование проекта имплементации инженерных практик. Сформирован набор инструментов и документации, позволяющий быстро развернуть окружение на любых проектах 1С.
Если говорить о сложностях с которыми я столкнулся во время реализации проекта, то они абсолютно такие же как в статье Сопротивления автоматизации тестирования. В 90% случаев связанны либо со внутренним сопротивлением компании на изменение существующей модели разработки либо отсутствием на тот момент достаточных знаний.
Что же касается личных результатов, то они такие:
В заключении, хочу сказать, что 1С хоть и медленно, но двигается к полноценному DevOps. В настоящее время достаточно инструментов для построения контуров, но несколько тормозит процесс развития — это недостаточное количество специалистов DevOps в среде 1С и незнание руководителей о существовании таких возможностей.
Буду очень признателен, если Вы приведете свое мнение о концепции DevOps в 1С. Чего по вашему мнению не хватает отрасли?
Перечисление примитивной настройки основных приложений. Как быстрое начало неплохо. Как обычно подробностей никаких.
Можно взять книжку, бутылку конька за эти же деньги и приятно провести время.
Книга - кусок позорища.
Первый раз, когда недоволен учебным материалом 1С.
Раздел особенностей работы с памятью по стилю речи и связанном и мысли напоминает речь пьяненького студента на кухне, который в предмете, может и разбирается, но связано сказать не может.
Кстати, сказанное про память оказалось для меня откровением и, дикостью, но своих 650 рублей оно стоит.
Я даже не знаю теперь, можно ли верить автору раздела про память. Я, конечно, инфу протестирую на практике, но когда это будет.
(15) ну вы же купили книгу.
Откройте страницы 246 и 249 и просто офигейте.
Просто офигейте.
Я вообще не понимаю, зачем надо было так делать и как эта 1Сочка еще работает.
Первое издание продавалось в электронном виде.
Но у него не было заявленных в (16) 246-й и 249-й страниц - заключение было на 219-ой.
(0) 2-е издание не читал. Первое проглядел мельком. Пользы от книги ноль, т.к. если ты в теме, то нового ты ничего не узнаешь, а если не в теме, то ничему не научишься.
(0) и первое и второе издание прочитал. Если вы имели доступ к ТВКВ + читали сабжи по теме на партнерке где-то за последние пару лет, то нового вы узнаете мало (если узнаете вообще) Если из вышесказанного вы не читали вообще ничего, то скорее всего, вы достигните какого-то уровня просветления.
Второе, кстати, издание получше чем первое.
У авторов какое-то дикое непоследовательное изложение материала для методического пособия. Например, приводят запрос как в PostgreSQL посмотреть список установленных блокировок. Но для MS SQL почему-то не приводят (наверно не осилили).
Особенно веселят скриншоты PostgreSQL на винде - ребята видимо никогда не работали с ним на линуксе в продакшене, а если не работали, то зачем тогда лить воду по этой теме?
На методическое пособие не тянет, так, сборник малосвязанных инструкций.
Читайте также: