0: Меня зовут Никита Иванченко. Опыт в айтишке больше 15 лет, и все это время я так или иначе, рядом с 1 эс начинал с маленькой франчайзи, потом в большой франчайзи, потом бигтех и финтех. И вот это все вот и занимал.

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

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

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

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

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

6: И там я могу ещё активно вам поотвечать, порассказывать. Если вдруг так случится, вам действительно это будет интересно.

7: Так, прежде чем я начну свой рассказ немножечко оо отусе это площадка с онлайн курсами для it специалистов курсов здесь очень много, они на разный уровень грейда от джуна до Лида, и они абсолютно по разным.

8: Тема не только разработчики могут найти что-то для себя интересное, также всевозможные аналитики data science, специалисты и прочие люди у отуса есть образовательная лицензия это говорит о чем о том, что вы можете получить по

9: Окончанию специальный сертификат, диплом и подкрепить, так сказать, своё резюме. Этим документом, как я уже сказал, направления курсов очень разнообразны. Есть дата сайнс, её тестирование аналитик, анализ

10: Управление безопасности и ещё много вещей, о которых я даже могу и не знать. Вот. Но все они есть, и их можно найти, пройти и получить тот самый диплом, о котором я говорил на предыдущем слайде сегодня, о чем я хочу вам поговорить. Хочу поговорить об автоматиза.

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

12: 1. Их много от торговли до управления складом бухгалтерии. Вот эта вот вся история и все эти люди из этой истории, они генерят нам какие-то задачи. Либо мы находим у них их сами. То есть у них есть некоторые процессы, связанные с их хозяйственной деятельностью.

13: Те, которые мы так или иначе автоматизируем. Зачем мы это делаем, чтобы повысить их производительность в 1 очередь, чтобы они могли сделать больше за

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

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

16: О разных этапах разработки и о тех инструментах, которые могут именно автоматизировать эту самую разработку на всех этих этапах.

17: Вот и двинемся немножко дальше. Небольшая предыстория, как обстояли у меня дела в 2010 году, когда я начал заниматься 1 эской, это выглядело так. То, что я приезжал к какому-то клиенту, я был, работал во франчайзе, и мне говорили, у нас

18: Не работает. Либо мы хотим вот это, либо им нужно было просто что-то обновить, какой-то релиз поставить. В общем я приезжал, открывал конфигуратор, прода и что-то там делал, что-то полезное, иногда не очень полезное. И за это меня благодарили. Вот.

19: Ну, в лучшем случае, что там могло быть, там могло быть хранилище конфигурации, ну, в этом, как бы, и все с тех пор.

20: 1 с. Ушла далеко вперёд относительно того времени, так сказать, отрасль немножко выросла, и я уже все чаще и чаще встречаю это какие-то команды на стороне непосредственно заказчика, которые сидят в штате и приносят какую-то полезную

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

22: В штате клиента, ну то есть для них в штате работодателя. Вот, и в силу разных причин не спешат как-то меняться, развиваться, пробовать что-то новое. Ну вот как-то вот так работает и вроде нормально вот.

23: И это может приводить, ну, так скажем, к разным возможным ошибкам, как человеческого характера, как замыленности. Ну, я не знаю, как у вас, но у меня были такие случаи, когда я, например, не тот дэтэшник или не тот техник загружал не в ту базу. Вот было

24: Неприятно, неудобно. Приходилось опускать глаза вниз, и я сейчас все поправлю. Вот с годами, как выяснилось, для меня иногда не во благо, а скорее вопреки вендору и.

25: И тем инструментом, который делает сама 1 эс, но все-таки инструментарий стал появляться, который помогал именно автоматизировать мою работу как разработчика. И давайте немножко посмотрим, как оно сейчас может выглядеть. Это такой обобщённый

26: Скажем так, процесс пайплайн разработки, ну, не только разработки, то есть вот от момента появления потребности у моего заказчика до момента, когда эта потребность реализуется в его продуктовой информационной базе, проходит

27: Несколько этапов. Вот, и от компании к компании эти этапы могут варьироваться, разниться, но я постарался вот к этому рассказу их все обобщить. Ну вот как-то. Так что плюс минус, наверное, это есть у всех в том или Ином виде, то есть

28: Изначально у нас есть некоторый бэклог, в который к нам приходят задачи. Задачи могут приходить по разному. Либо мы сами что-то нашли и решили предложить нашим заказчикам там что-то у них улучшить, либо пришёл сам заказчик, либо аналитик и сказал, вот мы вот

29: Страдаем. Давайте вот здесь сделаем лучше вот так вот. Ну либо просто случился какой-то баг, какая-то проблема, и она прилетела в нас, и её нужно исправлять. Вот также ещё задачи бывают очень тривиальные, обычные. Это как просто выходит новый релиз от нашего вендора. Новая бухгалтерия новая

30: Зарплата новая, вот все, что угодно. Подставь название конфигурации. Вот. И все эти задачи прилетают к нам в бэклог, их нам надо разбирать. Вот как мы их начали разбирать, мы их берём в разработку. Иногда они проходят дополнительно, там какой-то фильтр в виде аналитика, либо

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

32: Пишем вот наш код как-то вот как мы его пишем куда-то, потом его сохраняем и двигаемся дальше. У нас в лучшем случае должен случиться какой-то код ревью. Ну вот самый минимум просто какой-то сосед посмотрит по диагонали наш код и скажет ну

33: Да вот у меня глаз не замылен. Вроде все нормально. Где-то в лучших случаях могут применяться инструменты стат анализа. Их тоже несколько дальше я про них расскажу. И самый продвинутый случай это когда можно делать ревью с помощью искусственного интеллекта. Есть уж

34: Готовые инструменты, но на них я сегодня подробно останавливаться не буду. В силу 2 причин нету. Вот прям коробочного варианта взять у себя развернуть, чтобы просто работало и это. Ну дайте признаюсь, это достаточно дорого. То есть вот свои вот эти

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

36: С этим не согласится бизнес. Дальше у нас начинается этап тестирования. Тестирование тоже бывает разное. Ну, в 1 очередь, это как минимум ручное тестирование. Вот разработчик там кнопочку сделал, ну, как минимум у себя потом откроет какую-то разработческую базу.

37: Эту кнопочку нажмёт, убедится, что она нажимается вот лучше, когда рядышком есть аналитик, который ставил задачу, либо там представитель бизнеса, который ставил задачу, он тоже может понажимать эту кнопочку и убедиться скорее с бизнесовой части. То, что эта кнопочка делает то, что она должна была делать, то, как это описано в задаче. Вот

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

39: Шаг это у нас релиз. То есть то когда мы все это вот накодили и несколько наших разработчиков все это сделали, какие-нибудь задачи, пришло время завершать либо спринт, либо вот как вот можете у себя по другому называть. Ну вот несколько задач сложились в 1 место и готовы для того,

40: Того, чтобы отдать их заказчику в продуктовую базу. Вот. И в этот момент мы согласовываем время даунтайм. Ну то есть, когда система будет недоступна, когда мы выкинем пользователей, и мы как-то, эти, наши объединения, будь то

41: Техник, либо ещё каким-то образом мы это уже ставим в продовую базу. Вот такие основные шаги, этапы при автоматизации у нас есть. Дальше я хочу каждый этот шаг разобрать отдельно и описать, какие инструменты для автоматизации в том или Ином случае можно использовать и какие

42: Инструменты. Так, а пока я не двигаюсь дальше, я прочитаю, что вы мне написали относительно себя. Кирилл, разработчик 1 с более 12 лет пришёл послушать о реальном командном опыте работы связки и и 1 с. Да, про это расскажу. Архитектор хочу

43: Уменьшить рутинную работу? Отлично. Разработчик 1 с Ренат Евгений тимлид в команде разработчиков. Хочу узнать, как начать внедрение гид в команде. Разработчик 1 эс. Хочу послушать про опыт работы связки 1 с и гид тимлид. Послушаю, чего нового это написал.

44: Хорошо, надеюсь, я всем вам расскажу что-то новое. Так, слайдов, наверное, будет не супер много, но я буду много говорить голосом, так что двигаемся дальше. Вот и 1 этап, который идёт после постановки задачи, как нам уже

45: Все-таки задача пришла в том виде, в котором бизнес ожидает, что мы её начнём делать. Вот она к нам пришла, и у нас начинается разработка, она состоит из нескольких частей. 1 часть это среда разработки. Их на самом деле 2 старые добрые конфигура.

46: С которым уже, наверное, все знакомы, и старый, уже старый, но не совсем добрый пока ещё это едт. Вот также есть всевозможная экзотика, которой я не буду сегодня рассказывать, ну просто вот есть отдельные индивиды, которые всяких visual studio code.

47: Прочих редакторах пытаются там вести разработку, у кого-то это получается, но это прям путь для истинного самурая. Итак, остановимся на 2 средах, которые у нас есть. Это конфигуратор и едт и дальше

48: Это была среда разработки непосредственно. Есть тот предмет, с которым мы работаем. Это исходный код нашего приложения, то есть нашей информационной базы, нашей конфигурации. Другими словами, называйте, вот мы с ней работаем. И для того, чтобы с ней мог работать не только я, а ещё мой сосед.

49: Разработчик и возможно там несколько команд разработки вместе. Для этого нам нужно каким-то образом вместе интегрировать наш код. Вот это как раз та часть ci, которая в девопсе сайте интеграция кода. И для этого у нас тоже есть 2 инструмента.

50: 1 инструмент. Вы, наверное, все его прекрасно знаете, это хранилище конфигурации 1 с, оно тоже старое, оно по возрасту старше Гита. Вот. И у него есть и свои, как и плюсы, так и минусы. Дальше я их

51: Смотрю, и есть более современная система версионирования. 1 из них гид, с которой можно работать. На самом деле их больше. Но вот сейчас в айтишке, наверное, в основном остался только гид. Все остальное скорее исключение, чем правило. Вот, ну и

52: Что-то кроме хранилища конфигурации Гита, вряд ли я когда-нибудь встречал и когда-нибудь встречу в принципе рядом с 1 с. Поэтому вот у нас есть 2 такие системы.

53: И вот изначально, если смотреть на тулинг, который нам предлагает вендер, картина выглядит следующим образом конфигуратор умеет работать с хранилищем, но не умеет работать с гитом, едт, умеет работать с гитом, но не умеет с хранилищем из коробки эта вся история.

54: Однако до того, как появилось ееще едт, или до того, как оно стало хоть как-то распространено, что ей пользовались больше, чем 3 человека, кто-то уже научился работать с конфигуратором и гитом одновременно.

55: Поэтому картина на самом деле может быть выглядеть вот так не нативно, то есть там нету кнопочки там подключиться к ветке или как-то синхронизироваться в конфигураторе. Однако есть достаточно инструментов, которыми это можно автоматизировать. И все это

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

57: Очень много других каталогов, файликов, которые отражают исходники конфигурации. Это называется в формате конфигуратора. Это достаточно такой тяжёлый формат, в котором куча иксэмеле и бсэл файлов эксемельки это всевозможные

58: Описание структуры метаданных и структуры форм. Вот все, что описано в эксемель, он очень вербозные, то есть многословный и, скажем так, там много лишнего, ну, например, в метаданных какие-то значения

59: По умолчанию, которые у нас никак не изменены, относительно типового объекта, который мы создаём новый. И также на формах, они все равно вываливаются. Все достаточно такой сложной древовидной структурой. Вот.

60: И исходники, тексты модулей, они лежат как обычный текст в формате bas. Вот эту штуку мы можем выгрузить.

61: И как уже работать с этим? Ну, выгружать просто неудобно. Поэтому есть такая история, как называется пакетный запуск конфигуратора, но я про неё чуть позже расскажу. Так, а теперь вернёмся к едт. Как я уже сказал, едт прямо из коробки хорошо умеет работать.

62: С гитом, то есть там прям встроенный гит клиент, там можно переключать веточки, делать реквесты, то есть Межит код, делать черепики. То есть вот то, что есть во всей тишке, достаточно давно связано с гитом, оно из коробки уже есть в едт.

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

64: Наладить свой процесс для работы с хранилищем я этого не рекомендую, это крайне неудобно. И это очень негативный опыт в том плане, что если вдруг команда ведёт разработку в конфигураторе и на хранилище в какой-то момент принимается

65: Решение. Давайте мы попробуем едт н едт. Мы будем пробовать вот на чуть чуть на полшажка и на эти полшага мы начнём работать одновременно и немножко в конфигураторе немножко сохранился, немножко в едт появится куча ненужных

66: Фактов, проблем и сложностей, которые только отпугнут команду от работы в едт. Дополнительно к моим словам, ещё недавно появился, появилось расширение для едт, да, едт позволяет писать всевозможные плагины, которые в том,

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

68: Я его не трогал, поэтому мне сложно как-то это оценить, и я все-таки придерживаюсь того мнения, если уже начали работать в едт не надо вот этих полумер полкоманды работает в конфигураторе полкоманды в едт. Это я ещё ни разу ни от кого не слышал, что это было классно, удобно, это хорош.

69: Закончил.

70: Однако у едт тот формат, который она выгружает файлы, он отличается от того формата, который выгружает конфигуратор, он более плоский, то есть там, внутри, в структуре папок, нету такой сложной древовидной иерархии, там чуть более плоская и xml выглядят проще.

71: Например, как я уже сказал, если у нас относительно условно типового набора изменённых реквизитов там на форме или же в метаданных ничего не менялось, то объём x он будет сильно меньше, то есть там не будет выгружаться все настройки, которые есть по умол.

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

73: Вылетело на пол экрана обновление зума, я че то отвлёкся. Итак, в общем, формат, он проще и легче, и более плоский. Какие ещё могут быть отличия и сложности в формате конфигуратора, когда вот вы, допустим, работаете с версией платформы 8,

74: 3 27, какая-нибудь 0 0 1. Да, и выгружаете, загружаете исходники. Команда себя прекрасно чувствует, работает. Потом взяли, обновили платформу, там на 8 3 27 уже не 0 0 1.

75: Там 105 например ну немножко поменялось ну как была 27 так и осталась, то на следующей выгрузке новой платформы абсолютно все xml файлики они поменяются вот место там в шапке вот этого xml файла есть там 1 из последних Ключиков.

76: Версия в формате, там она 2 точка 21 была допустим а станет там 2 точка 22. Ну либо какая-то другая циферка будет но тем не менее, все оно поменяется. И для того, чтобы переходить на новую платформу, это надо делать очень аккуратно и все вместе и

77: На каждый переход делать отдельный такой коммит в гитрепозиторий, чтобы не было лишних конфликтов. Тот, ну, например, разработчик начал делать свою задачу на версии там 1 платформы, потом вдруг все реши.

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

79: На это надо обращать внимание и как я там дальше? Сейчас покажу конфигуратор с гитом это для ловких и умелых. А вот подключение едт к хранилищу это прям какой-то атавизм, это как поставить там кассетную или дисковую магнитолу в новую теслу.

80: Если уже пошли в едт, то пользуйтесь всеми благами, которые там есть.

81: Итак, по поводу хранения кода, немножко про хранилище, как вы все знаете, хранилище оно линейное. Что это значит у нас? Вот оно 1, по сути, и это веточка. Мы сделали доработочку, новый коммит, новый коммит, новые изменения, новые изменения, оно

82: 1 за другим идёт и уже какую-то ветвление разработки сделать достаточно сложно. Соответственно, о чем я говорю. Вот предположим, я сел и начал делать какую-то большую длинную задачу, где мне нужно сделать много новых методанных, там каких-нибудь регис.

83: Справочников, документов добавить. Ну, прям долгую неделю надо делать. Соответственно, я там захватываю, ну, например, корень, потому что мне нужно добавить новые объекты, я их начинаю добавлять ещё там пишу какой-то код, где-то, какие

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

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

86: Ология, это я ещё 1 работаю. А представьте, если несколько человек, надо как-то там друг у друга корень просить отдать, чтобы новые объекты создать, при этом как-то не помещать. Ну, в общем, не очень удобная история в плане групповой разработки. С 1 стороны, она удобная. Вот когда

87: Начинаются какие-то там угловые кейсы, то уже это удобство все куда-то улетучивается. Вот есть методология даже на сайте итс называется методология разветвлённой разработки 1 с где там предлагается иметь продовые хранилище и иметь

88: Доработ, ну как бы делать доработки через поставку от текущего продового состояния. Тоже подход тоже удобный. Некоторые его дополняют несколькими хранилищами. Там кто-то делает хранилище, деф, кто-то делает 3 хранилища, и вот там как-то все

89: Между собой межет, но все равно в конечном итоге у нас будет игра через сравнение, объединение через

90: Через сравнение объединения и через поставки, и тут, как как ни крути, все равно будут конфликты, когда людей много и нужно будет эти конфликты разбирать через сравнение объединений, поэтому у хранилища есть

91: Определённые плюсы, оно нативное, работает из конфигуратора и достаточно понятно, все умеют с ним работать, оно простое, оно существует давно, работает как часы, практически не ломается, если правильно его обслуживать и все как будто бы хорошо.

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

93: За счёт того, что оно медленное, его не очень удобно использовать для кодревью. Опять же оно блокирующее. То есть мы захватываем какой-то объект, больше никто с ним работать не может. И как будто бы это должно помогать мне не попадать на конфликты вместе с моей командой.

94: Ну, опять же, конфликты все равно будут, потому что задачу нужно отпускать. Либо мы не помещаем что-то недоделанное, и в итоге все равно где-то сравнение объединения с конфликтами, мы столкнёмся так или иначе, несмотря на то, что оно блокирующее и оно централизованное, что это значит?

95: У нас есть где-то сервер хранилищ, либо каталог, который является хранилищем файловый. Мы все должны к нему подключиться, чтобы начать работать. Если я не смог подключиться, то удобно работать я не смогу.

96: Что у нас дальше? У нас дальше есть гид, он имеет то, что является минусами хранилища, у него в принципе является плюсами, он децентрализованный. То есть я могу непосредственно сейчас не иметь доступа к

97: Удалённому репозиторию спокойно с ним работать, за тем исключением, что я не могу туда ничего отправить и ничего оттуда забрать. Также я могу спокойно переключаться с веточки на веточку, пока с ним не работаю, оно не блокирующее. То есть я могу работать с каким-то объектом конфигурации. Сосед мой может работать.

98: Объектом, да, если мы поработаем вот прям очень, очень рядышком, скорее всего, мы нарвёмся на конфликт, который нужно будет решать условно через сравнение объединение, но конфликты в гите считаются по строкам, ну то есть, если я внизу модуля что-то поменял,

99: А мой сосед разработчик, поменял что-то вверху модуля в разных строчках. В таких случаях гид может разрулить этот конфликт на автомате. Ну потому что он эти изменения смотрит построчно, конечно, если мы все переформатировали вот так в модуле, то

100: Там уже надо будет посидеть и включить мозги. Так, децентрализованное, но не блокирующее. Оно быстро работает в том плане, что в гите очень можно быстро посмотреть историю по конкретному файлу, по конкретной строчке.

101: Кода, либо можно очень быстро откатиться на какую-то предыдущую версию и посмотреть исходники, как оно было там. Либо я могу прям вот где то что-то не работает. Я увидел в коде где-то что то плохо я могу посмотреть прям встать на эту строчку, либо

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

103: Вот, потому что его нет, да, то есть я могу спокойно, как я уже сказал, работать с какой-то 1 длинной задачей. И в какой-то момент, когда мне срочно прилетает от бизнеса, вот здесь вот нужно, Никита, что-то срочно исправить. Я могу эту веточку, в которой я

104: Работал что-то долго сохранить, переключиться на другую задачу с ней поработать, её быстренько исправить, отмееить и отправить куда надо, дальше на ревью и потом вернуться спокойно к своей задаче. А когда относительно моей задачи прост, далеко ушёл вперёд я эти изменения

105: Тебе могу тоже подтянуть, поэтому это удобно дополнительно. Как только мы начинаем работать не с бинарным хранилищем, а с непосредственно с файлами, и которые хранятся в гите. То есть это просто текстовые файлы у нас сразу открываются, но

106: Возможности удобного код ревью. Это все можно быстро глазами посмотреть, дать обратную связь. Если использовать тот или иной гид, сервер, можно прям вот оставлять комментарий на код ревью относительно той или иной строчки кода, где мне что не нравится, либо блока.

107: И перед нами открываются дополнительные возможности статистического анализа. Ну то есть мы можем некоторые использовать инструменты, которые будут смотреть наш код и проверять его на соответствие тем или иным стандартам, либо каким-то другим правилам, ну либо просто видеть задублированный код, то есть

108: Там много раз контрол ц контрол в делал там какое-нибудь условие цикла, на меня посмотрят эти инструменты, скажут, зачем ты здесь задублировал. Давай, как бы вынеси это в какой-то отдельный метод, например.

109: Из минусов. Нет, конфигураторе. Это многих останавливает, они вот смотрят, вот все у нас, у нас только хранилище в конфигураторе и все. Мы дальше никуда не пойдём. Также это как не то, чтобы минус, но многим 1 сникам, которые пришли из хранилища, где они могут заблокировать

110: Никто другой его поменять уже не может, здесь такого нет, он не блокирующий, он допускает конфликты. То есть он просто допускает 2 людям параллельно редактировать один и тот же объект. Ну будь то метаданные, там добавлять либо редактировать какой-то модуль.

111: Ну и самое главное, гид, он чужд обычному, 1 с разработчику. Ну просто потому, что в стеке одинэсника его никогда не было. Вот давно едт вроде как уже 9 или 10 лет существует, но она не распространена. И многие 1 эсники, ну просто они

112: От Гита. И вот на этом все так вот исторически сложилось. Но тем не менее, если посмотреть любой другой стек айтишный, где есть разработка, знание, базовые Гита уже должно быть, ну, наверное, на уровне стажёра.

113: Вот где-то там и на самом деле в гите нет ничего сложного, можно найти любой видосик на YouTube RuTube и так далее, который занимает примерно час времени, там базу объяснят, потом почитать документацию, гитбук и в принципе.

114: Этого будет достаточно просто, чтобы начать работать.

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

116: Там уже гид есть из коробки. Если вдруг вы работаете в едт, вы уже умеете гид и следующие 2 слайда можно пропустить. Вот. Но, тем не менее, для тех людей, которые, ну, просто давно работают в 1 с и работают с хранилищем. 1, что мы можем сделать, которое

117: Условно бесплатная, то есть не нужно ничего команде нового знать. Команда продолжает работать так же, как работала с хранилищем, но мы сбоку пристраиваем такой инструмент, который называется git синк вот здесь, внизу, есть ссылочка. Что это такое? Это инструмент.

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

119: И отправлять в какой-то гид репозиторий, запустив его единожды, можно подождать, он обработает всю историю, догрузит и дальше периодически запускать, он будет новые версии докидывать в хранилище.

120: Зачем это может быть нужно? Ну, во первых, это такой мосточек к новому миру, как я уже говорил, вот есть определённые плюсы у Гита. Во первых, можно делать уже более удобный код ревью. То есть разработчики как будто просто работают и кладут свои задачки.

121: Хранилище конфигурации ну, оно куда-то синхронизируется, и в это куда-то можно потом зайти, посмотреть, связать по ссылочке, допустим, задачу жира с тем, что прилетело в git репозиторий, и там сделать код ревью, то есть заходит там тимлид, либо сосед, либо сеньор.

122: Какой-то, ну это как процесс постройки и посмотрит. А что ж там ты, дорогой мой друг, наменял и может дать обратную связь прям написать непосредственно комментарии к тем или иным строчкам кода. Вот так как это такой мосточек. 2, что можно прикрутить. Давайте сделаем

123: Помимо удобного кодревью можно потом очень быстро смотреть по истории, то есть этот инструмент, когда выгружает. Если его правильно настроить, он может персонально мапить тот пользователя в хранилище с каким-то

124: Пользователем, заведённым в том же там гитлабе, например, либо другом гит сервере. И там после выгрузки будет прям история. Можно остановиться на строчки, нажать там Гитлейн, если мы говорим про гитлаб и он выведет историю, кто менял

125: Эту строчку, кто когда что сделал это по поводу быстрого поиска и так как у нас уже выгружены все наши исходники в разрезе коммитов хранилища в гитрепозиторий, можно подключить всевозможные инструменты.

126: Статистического анализа, вот прям не отходя от кассы, потому что оно уже у нас есть вот как я сказал, это вот 1 шаг мосточек, с которого можно начать и посмотреть какие-то определённые плюсы гесинка и guitar, в целом не отходя от хранилища далеко.

127: Вот следующим шагом, может быть, когда мы будем пытаться уже из этого гит реппозитория. Ну, например, после того, как мы стали делать код ревью и прочие всевозможные стат анализы, собирать какие-нибудь релизы оттуда, это

128: Следующим шажочком, после того, как мы уже освоились и привыкли смотреть не только в хранилище, но и в какое-то другое приложение, например gitlab и разбираться там.

129: Vendor я не помню, с какого релиза, я уже говорил, что не помню, дал нам очень классный инструмент пакетный запуск конфигуратора, то есть мы можем наш экзешник 1 с 8 запускать определёнными ключами и будем добиваться определённых.

130: Ну, например, там есть много, много параметров, в том числе можно запустить его, как предприятие, передать там какую-нибудь обработку на запуск, либо запустить конфигуратор тоже с какими-то определёнными командами. Вот 1 из этих команд это выгрузить, либо загрузить конфиг.

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

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

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

134: Где-то на пол экрана и этим пользоваться можно, но этим пользоваться не всегда удобно. Вот особенно когда у нас там версия платформы меняется вот ещё что-то такое нужно будет постоянно че то переписывать, либо сверху вот этого пакетного запуска каким

135: Своими скриптами, батниками, шелл, скриптами, питоном, чем-то угодно делать обвязки, чтобы это стало удобно на самом деле, чтобы это стало удобно. Вот эти обвязки делать не надо. Для вас уже это все сделало сообщество и для

136: Такого инструмента, как Ван скрипт, есть библиотека, которая называется на сегодня. Я про скрипт не буду рассказывать. Ну, потому что если я про неё начну, это будет долго, я люблю про него рассказывать. Но сегодня мы про его библиотеку. По сути, это утилита командной строки, которая устанавливается. Ну,

137: А что такое утилита командной строки, если вы откроете терминал в виндовсе, там цмд вы можете написать ping и там какие-то ключи передать и он там че то пропингует, там яндекс какой-нибудь или что-нибудь ещё. Вот когда вы вводите какую-то команду в консоли, передаёте в неё параметры, это называется интерфейс командной строк.

138: Вот ванесса раннер, это утилита, тоже интерфейса командной строки. То есть можно написать в runner и передать какие-то ключи, произойдёт какая-нибудь магия? Ну, не будет, конечно, яндекс пинговаться, но будет что-то другое. На самом деле, ванесса раннер это такой швейцарский нож.

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

140: Как бы там внешние отчёты, обработки и многое другое. Также ко всему прочему, она умеет работать с автономным сервером. Это бывает очень удобно, когда мы, допустим, хотим какие-то процессы ускорить, ну там, выгрузку, загрузку.

141: Ну не надо только в prod автономный сервер ничего грузить, потому что это чревато опасностью всякие там death контура за милую душу вот и как мы знаем, автономный сервер, он умеет запускаться в режиме предприятия, чтобы в нём можно было поработат.

142: Либо в тонком клиенте, либо в веб клиенте. То есть он сам себя публиковать умеет. И когда мы его запускаем, самая его кайфовая вещь, которая принесла мне очень много удовольствия, он позволяет работать без использования лицензии 1 с предприятия, где это может быть?

143: Это может быть полезно во всяких контурах автоматизации, когда мы хотим запустить какие-нибудь тесты в изолированном пространстве, о чем я говорю. Ну, например, у нас есть автотесты, связанные там, сценарные тесты.

144: Дальше про них расскажу. Ну, сценарные тест это когда мы на автомате что-то запускаем, предприятие на автомате, кнопочки прожимаются, и мы убеждаемся, что кнопочки работают, у нас ошибок не выпадает. Вот. И до этого момента приходилось как-то очень подбирать контура, чтобы там была 1

145: Возможно чтоб там был 1 с server была какая-то доступная база и так далее вот теперь все это можно немножко опустить в сторону и с помощью вот этого инструмента ну просто автономного сервера, но рендер он позволяет очень удобно работать.

146: Автономным сервером, например, шаги такие, как загрузить конфиг, создать пустую базу, загрузить туда конфигурацию из исходников, запустить автономный сервер и запустить там тесты. Это все делается там 3 относительно короткими командами без вот

147: Этих вот длинных путей и the runner. Он дополнительно умеет, допустим, находить последнюю версию платформы либо нужную версию платформы. То есть у меня там идут тесты на 8 3 25. В какой-то момент мы там доставили 27 я хочу проверить, как мои

148: Отрабатывает сборки на 27 платформе. Я просто дополнительный ключик даю, там версия платформы, там 8, 3, 27 условно. И у меня также дальше тест поехали, он сам найдёт установленную платформу, все запустит и все сделает. Вот. И если мне нужно просто

149: Все те же операции сделать через автономный сервер я дополнительно дам 1 ключ айбиси либо ib серви в зависимости от того, что мне нужно и все, и дальше он уже сам запустит автономный сервер, если установлен как компонент и сделает все как надо вот очень.

150: Полезный и удобный инструмент в абсолютно разных разнообразных кейсах применения.

151: Вот так. Ну и вокруг этого можно уже сделать обвязки для разработчика. Там 2 батника, который будут выгружать, загружать. Он работает спокойно в конфигураторе, нажимает кнопочку, исходники выгрузились, он дальше там открыл свой любимый гип клиент, что-то

152: Закоммитил, отправил свою веточку и дальше работает, как я говорил, это, ну, немножко для ловких и умелых. Ну, потому что чуть больше, чем просто подключиться и поработать с хранилищем. Надо немножко изучить, как работать с гитом и сделать пару батников для

153: Такого разработчика. У меня был такой опыт. Достаточно давно без едт работали в конфигураторе, используя гид. По Такому опыту могу сказать, разработчику нужно примерно неделя, может быть, 2. Ну, чтобы начать в этом рабо.

154: Комфортно, как будто он в этом работает очень давно. То есть 1 время что-то непонятное подсказал, как здесь, как там и дальше он уже прекрасно справляется. Не надо недооценивать 1 эсников, они, ну, достаточно в большинстве своём и молодые специалисты, и специалисты.

155: Работают давно и если прям сопротивления нет какого-то там психологического, они достаточно быстро осваивают этот инструмент и прекрасно с ним работают.

156: Так, и что мы проговорили про разработку, как её можно автоматизировать и есть у нас едт там особо автоматизировать в этом плане не надо. Она сама умеет синхронизировать базу данных с конфигурацией, которая лежит в

157: На диске, и там есть гип клиент и там как будто бы уже все хорошо. Вот дополнительно к этому внутри едт, когда вы её устанавливаете, там ещё есть такой инструмент, как называется едт силай ли это тоже инструмент интерфейса командной строки, который позволяет

158: Из командной строки, так же, как, а вызывать саму едт и давать ей там всякие команды, ну, например, выполнить проверку проекта, там, ну, вот, едтнственного сконвертировать из 1 формата исходников, допустим, из формата едт в формат конфигуратора, либо наобор,

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

160: Пока в свою жизнь прибавлять едт и длинные эксепшены, которые может едт отдавать вот для них, ну, либо пакетный запуск конфигуратора, но не сильно удобный. И прям ранее это стандарт в этом плане. Ну,

161: Тех, кто пока особо гид не хочет, но все-таки 1 шаг сделать надо, то можно взять просто git синк и начать сбоку поставить, пусть он выгружает хранилище и потихонечку туда людям показывать. Вот смотрите, здесь можно быстро посмотреть историю, кто какую строку изменил.

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

163: Так, по времени прекрасно укладываемся, двигаемся дальше. Это я вам говорил про разработку, здесь вроде все понятно и мы дальше видим нашу историю. Это код ревью и стата анализ. То есть когда мы

164: Поработали мы, напилили нашу фичу, мы её отправили тем или иным способом гитрепозиторий. Будь это там ддт, там либо сами запушили руками, либо за нас это сделал. И ну вот как-то мы донесли наш ci контур от непрерывной интегра,

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

166: Что с ним надо сделать? Надо провести code review. Код ревью это процесс оценки произведённых доработок, изменений в коде, изменения в метаданных, на какие-то определённые соответствия критериям качества. Критерии качества могут быть разные. Это соответствие стандартам как стандартным.

167: Которые у нас описаны, нас либо стандартно внутри команды вот сделать вот так, а вот так не надо делать. Часто выбирают. Вот у нас есть компания ооо рога и копыта, значит у нас должен префикс рк, нижнее подчёркивание, что-то там и вот какие-то свои

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

169: Code review мы делаем на соответствие требованиям бизнеса. Ну, допустим, бизнес написал, я вот хочу, чтобы у меня при проведении счета автоматом, не знаю, сохранялось что-нибудь куда-нибудь и отправлялось, и отправлялся этот счёт менеджеру клиента, например, вот, и код

170: Смотрит. Ну, действительно, разработчик реализовал эти требования в том виде, в котором перед ним их поставили. Ну, разработчики бывают разные. У нас приходят и стажёры, и молодые ребята, и за ними нужно приглядывать, ну, в силу того, что они неопытные, что-то могли упустить.

171: Либо ещё что-то не так сделать. Возможно мы поймём, что нам было неправильно описано задание изначально. Ну и ещё код ревью это обычно корректность архитектуры, что разработчик не сделал лишних регистров, сведений, которые не

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

173: Человек глазами. Вот это не всегда. То есть это всегда нужно делать, но иногда для того, чтобы облегчить жизнь человеку, который делает это глазами, чтобы он не все подряд вчитывался и проверял часть этапа. Кодревью можно

174: Автоматизировать. Для этого тоже есть специальные инструменты, которые не заменяют человека, но сильно облегчают ему работу. То есть ему уже не нужно там вчитываться в каждую строчку и проверять вот как на соответствие стандарту, что там после запятой там сделал пробелы, вот эти все вещи.

175: Он может потратить на время своё, на более творческую проверку, там, на архитектуру, на применение там требований и так далее. Именно бизнесовых и инструментов автоматизации. Есть несколько 1 инструмент.

176: Котором я расскажу. Вы, наверное, про него слышали. Это автоматизированная проверка конфигурации апк. Она, по моему, входит в состав кип. Это конфигурация 1 сная, которая умеет проверять исходники конфигурации на соответствие всевозможным. 1 сным стандартам.

177: И рекомендации, как правило, её мало кто где использует, пока не начинают разрабатывать какой-то отраслевой продукт, в рамках которого они хотят получить статус 1 с совместимы. Вот если вы где-то были в команде, кото

178: Делал какой-то продукт, который выходил на 1 с совместимо, скорее всего, хотя бы 1 раз. Apk вы это видели и запускали, ну либо кто-то, кто у вас этим занимался, этим запускал. Вот, ну многие, когда запускали потом, ну, в каком-то непрерывном процессе эту штуку,

179: Дальше крутят и используют. Я в личном опыте, особо ей не пользовался в силу разных причин. Наверное, потому что я никогда такие продукты под совместимы не делал. Но есть 2 продукт, которым я очень много пользовался, и он мне нравится.

180: Больше, ну не потому, что лучше, а потому, что мне нравится больше. Это называется сонарку. Это, так сказать, это целая платформа для того, чтобы внедрять такой термин quality gate или оборот качеств.

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

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

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

184: Его ставят. Это как раз одинэсники. Удивительно, да, вот этот и есть платный плагин с более расширенным набором проверок. Вот я его сейчас не буду обсуждать. Я, как правило, мне хватает вот этого комьюнити опенсорсного

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

186: То есть он может где-то поругаться, твой код вот здесь вот не соответствует стандарту, и он даёт прям ссылочку на spark, где есть описание, вот что ты сделал, как надо было сделать правильно, и ссылку на its, почему вообще надо было так делать, вот, и там помимо проверок на

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

188: 5 циклов внутри условия это все читать невозможно, когнитивная сложность зашкаливает непонятно. Смотришь какие-то леса горизонтальные у тебя на экране, но вот он все это тоже умеет подсказывать и говорить то, что здесь стоит переделать.

189: С последними изменениями, по моему, их сегодня опубликовали. Он ещё умеет смотреть одновременно в контексте и конфигурации, и расширения этой конфигурации. Ну, например, раньше он ругался, если вы используете какой-то метод,

190: Расширение, которое принадлежит конфигурации. Там он мог ругаться то что типа я не знаю, что это такое вот сейчас он уже умеет смотреть в контексте и расширение, и конфигурация вместе. Вот, плюс дополнительно вы эти проверки можете видеть, если вдру

191: Вы когда-нибудь открывали с плагинами? Вижу студия, код там какой-нибудь 1 эс, он там тоже всякие проверки выдавал, вот эти проверки, они, они одинаковые, они один и тот же backend используют.

192: Также там, если мы интегрируем в какой-нибудь сервер, ну например, там тот же самый гитлаб гит флик, то есть возможность такой настройки, что когда мы какие-то помещаем изменения,

193: Кит автоматом, они начинают проверяться сонаром. Если сонару что-то не нравится, он прям обратно в гит сервере пишет комментарии к строчкам, что ему не понравилось. Это хорошо встраивается, когда, допустим, у нас есть история с реквестами.

194: По, в зависимости от того, какой инструмент используем. Ну, в общем, запросы на слияние, да, когда у нас есть девелоп ветка, мы от неё начинаем ветку какой-нибудь фичи там разрабатываем, потом открываем запрос на слияние и в этот момент у нас включаются все проверки, проверяется.

195: Запускаются и в том числе и он прям в комментариях к этому запросу на слияние пишет, где у тебя что не соответствует стандарту, где ты там делал копипасту всяких возможных. Иначе если иначе, если где-то и сделал там что-то неправильно, тебе подскажут.

196: Комментарий он прям вывалит автоматом, вывалит без участия человека в тот самый запрос на слияние. Вот, и к чему я все это говорю для того, чтобы снизить вот эту нагрузку, делать код ревью, 1 человеком, да, вот, который должен все проверить, он

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

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

199: Запустить его, установить и прописать ключи, создать проект. Это все будет работать. Здесь больше сложность не техническая, а политическая, скажем так. Ну потому что я очень много видел ситуаций, когда вот мы внедрили 100, они поставили

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

201: Здесь что-то сделал не так, пожалуйста, исправь. И что с этим все делают, ничего не делают, игнорируют. Ну там что-то написал. Мне срочно надо другую задачу делать. И как бы тут бизнес не ждёт. Вот это самая частая проблема, которую я встречал, мы как будто бы на внедрили, но мы им не пользуемся.

202: Так делать не надо. Вот если решили внедрить и точно пользоваться, то пользуйтесь это, потому что поначалу будут ругаться, будут ругаться на какой-то там legacy, код. А потом уже все войдёт в привычку и редко когда будет стрелять. А тебя

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

204: И, ну, потому что это выстрадали, там на автомате мышечная память пошла. То есть, какие-то моменты можно даже не спрашивать. То есть, а у нас там был, на, вы использовали, да, использовали, ну и tm пару вопросов задаёшь. Нечто реально использовали. И дальше по стандартам человека особо гонять не надо.

205: Так что мы ещё раз говорим ревью. У нас есть автоматическая проверка кода, и у нас есть сонаркуб с комьюнити плагином для того, чтобы это нормально. Работал сонаркуб. Там ещё надо несколько плагинов поставить, например, там, чтобы он мог работать с разными

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

207: И, как я уже говорил, заострять внимание не буду. Есть всевозможные инструменты для анализа кода с помощью иишек. 1 из них, который мне нравится, но который тяжело использовать в какой-то кофе. Он называется код ребит, ну,

208: Во первых, чтобы его на полную катушку использовать, нужно ему платить как-то в долларах. И во вторых, мы должны код куда-то ему отправлять далеко и ещё ему доступ к себе в инфу сделать, чтобы он мог видеть наш гид репозиторий и там че то комментировать. Вот никто в нормальном здравом корпе на это не согласится и

209: Это не взлетит, но он классно все-таки умеет понимать 1 с. Иногда просто диву даёшься, что он там выдаёт. Вот есть варианты, которые позволяют так или иначе это локально у себя развернуть.

210: Пользовать, но это пока дорого и непонятно. И прям вот по 1 клику коробки нет, возможно чуть позже что-нибудь в этом случае появится и как-то отдельно потом про это буду рассказывать. Но пока я таких инструментов не подобрал, чтобы это прям вот можно было раз

211: Человеку дать. И у него это заработало даже на ноутбуке. Вот это инструменты, связанные с ревью и с автоматизацией. То есть я на каждом пункте рассказываю про то, как автоматизировать те или иные случаи, пока это все отдельные автоматизации, там того или иного пункта.

212: А в конце я расскажу как это все можно, какими инструментами это все можно объединить в какие-то там конвейеры. Вот дальше мы говорим про тестирование. Это тоже важный аспект, который на который многие

213: Закрывают глаза, но он 1 из моих любимых. Вот я очень люблю тестирование. Вот оно бывает разное. Сейчас я вам про него расскажу и про каждый пункт расскажу, каким инструментом он потом автоматизируется.

214: Если в общих чертах у нас тестирование бывает функциональное и нефункциональное, нефункциональное, это всякое нагрузочное тестирование, ну то есть там, где мы не проверяем какую-то функциональную логику, а вот именно то, что у нас в принципе все работает либо под нагрузками, либо просто запускается, собирается и так далее. Вот.

215: Функциональное функциональное тестирование это, например, модульное тестирование или, другими словами, юнит тестирование для него есть в 1 с несколько инструментов. Я вот называю 2, которыми сам пользовался. Они более менее распространённые, это

216: Ванесса адд и x юнит ванесса адд. Он появился чуть раньше. И яикское, наверное, сейчас самый распространённый мой любимый инструмент для модульного тестирования. Он классно интегрируется в едт, то есть там тесты можно прям.

217: Запускать и видеть результаты, как они прогоняются. Вот модульное тестирование подробнее потом про каждый способ расскажу сценарное тестирование. Это когда у нас идёт проверка по сценариям. То есть у нас вот есть интерфейс и там какие-то сценарии

218: Пользователя надо отработать. Есть дымовое тестирование. Это когда мы

219: Не описывая какую-то определённую бизнесовую логику, проверяем работу системы. Ну, например, самый там яркий пример домового тестирования. Когда мы просто берём порядок, все подряд, все формы пытаемся открыть и закрыть, открыть и закрыть, либо там создать новый объект, записать его, либо существующий.

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

221: Видишь, чтобы там на каждый релиз, на каждую доработку запускалось всегда нагрузочное тестирование. Почему оно дорогое? Ну потому что это надо

222: Инфраструктуру, полную прода, там, сервера приложений сервера субд как-то с такой же конфигурацией поставить рядышком, чтобы не шатать прод и проводить там нагрузку. Ну чуть дальше про нагрузку тоже поговорим. Вот, и почему это дорого? Ну, потому что

223: Всегда имеет возможность вот прям скопировать контрол ц контрол в сделать железяка, которая у нас есть на проде, чтоб как-то убедиться, что эти изменения поведут себя также. Итак, давайте немножко каждый пункт разберём по отдельности модульное юнит тестирование. Здесь пример теста.

224: X. Юнит в чем вообще смысл юнит тестирования это те тесты, которые мы описываем кодом на языке? 1 с предприятия, и общий вид теста всегда выглядит так. Мы сначала готовим какие-то данные, потом.

225: Над этими данными вызываем какие-то процедуры или функции и потом проверяем результат. Вот хороший пример. Допустим, нам нужно проверить то, что при проведении документа у нас

226: Регистре, остатки товаров. Появляется новый остаток. Соответственно, что мы должны сделать? Мы должны сгенерировать новую номенклатуру, сгенерировать там все нужные данные, сгенерировать документ, вызвать у него метод провести и потом проверить, что в регистре у нас лежат нужные данные, а потом мы должны проверить.

227: Логику, что у нас не должно, должен документ проводиться. Если у нас нету остатков на списание, то тогда мы пишем другой тест. Мы сначала кладём также номенклатуру, генерим остатки в регистре по этой номенклатуре и потом документом пытаемся провести списание. Только мы спи.

228: Положили остатков 5, а списать пытаемся 10. И мы ожидаем, что у нас документ должен упасть в ошибку. И все это мы обязательно описываем кодом, тестами, то есть тесты описываем кодом на языке с предприятия. Это моё любимое. Ну, потому что я сам одинэсник, я пишу код на 1 эс, и мне удобнее писать тёс.

229: Тоже на 1 с модульные тесты, как правило, очень короткие, маленькие, они должны проверять там 1, ну или пару методов, которые у нас есть. Ну, метод, либо процедуру, либо функцию, которая мне очень важна, допустим, которая находится в программ.

230: В интерфейсе того или иного модуля. И, во первых, хочу убедиться, что я его сейчас сделал корректно, он работает так, как я ожидаю. И во вторых, я хочу убедиться через полгода, когда у нас система там пережила, там не 1 обновление и пару доработок, что

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

232: Надо писать вот данные, надо генерить, неудобно. А давайте я лучше че то какому-нибудь бизнесу приятное сделаю. Начинаются вот такие вот разговоры, но на самом деле, если чуть чуть себя заставить и подольше пописать тесты, то это то

233: Войдёт в мышечную память, кодовая база обрастёт новыми тестами. Появится уверенность в том-то, что у нас, ну, условно, там какой-то уже блок покрыт тестами, и мы там можем спокойно его дорабатывать, либо рефакторить. И у нас, если сломается, мы

234: Это увидим. Ну и когда вы пишите, начинаете писать тесты со временем, когда вы уже сейчас тест не пишите, вы пишите код новый, но в голове держите, что вы будете его тестировать. И вы уже понимаете, что вот так, вот так.

235: Писав код, мне его будет проще протестировать. А потом, когда ещё через полгодика посмотрите то, что код то теперь уже более структурирован, более декомпозирован и он выглядит лучше и за счёт того, что вы его покрываете тестом, или вы его писали с расчётом на то, что вы будет

236: Покрывать его тестами. То есть именно культура архитектуры кода тоже становится лучше за счёт того, что он покрывается тестами. Ну как, как факт такой, как данность уже за всеми это наблюдаю, замечаю. Вот как я уже сказал,

237: Есть несколько фреймворков, самый новый, самый распространённый на текущий момент, наверное, самый удобный это я. X юни, это расширение, которое даёт, ну, условно, там набор общих модулей, которые позволяют удобно, проверять, удобно.

238: Данные и удобно матировать данные, то есть так как это расширение, предположим, у нас часть кода, которую мы вызываем, должна написалась давно не очень корректно, и она, например, ходит в какой-нибудь там верстовые

239: И получает валюту, а нам получать не надо. И вот этот метод, который ходит, мы можем затянуть в расширение, сказать, что всегда получать там условно, валюту 30 ₽. Вот как оно было раньше, да, за доллар. А дальше логику проверяй, так как это расширение, оно позволяет вот именно заменять пове.

240: Каких-то методов, которые нам мешают покрывать тест. Это называется мокирование. Вот подробно на этом сейчас останавливаться не буду. Но имейте ввиду, что такое есть. Дальше о чем хочу поговорить это сценарное тестирование, это девелопмент.

241: Здесь на скриншоте пример как раз сценарного тестирования автомейшн, это, ну, наверное, тоже сейчас самый удобный, самый распространённый фреймворк для того, чтобы делать, проводить сценарное тестировании.

242: Вот сценарное, оно отличается от модульного тестирования. Как я говорю, модульное. Мы пишем код на языке. 1 эс, который что-то проверяет, ну либо в контексте сервера, либо в контексте клиента. Мы все равно пишем код руками. Сценарное тестирование, оно другое, оно работает

243: С интерфейсом пользователя, то есть мы описываем на языке гиркин сценарий, что должно произойти. То есть мы описываем, я запускаю тестовый клиент под пользователем с правами. Условно, там, ивано

244: Запускается и дальше я говорю, я Иду в подсистему такую-то, в список документов, реализации товаров и услуг, нажимаю там создать новый документ, там какие-то кнопочки по документу нажимаю, потом проверяю, что у меня документ провёлся, например, в печатной форме.

245: Внизу в самой там какой-нибудь клеточке количество товаров равно там 5 и сумма товаров равно 10, потому что цену посчитать. Вот это все работает от пользовательского интерфейса. И вот эти сценарии, которые мы описываем, что должно происходить, мы описываем то какие действия

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

247: Немножко попрограммировать с точки зрения, что, куда нажать, как это дело проверить, какие результаты ожидать.

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

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

250: Который у нас появился достаточно давно в платформе. Это менеджер тестирования и клиент тестирования. Только там это все писало на эксемельки, на генерации этих иксэмеле кода, на 1 эссе. А здесь это штука доступная.

251: Ну, грубо говоря, там, допустим, не знаком с программированием, людьми, то есть, в принципе, продвинутые какие-нибудь функциональные архитектора, либо аналитики, либо даже бизнес аналитики, они могут тоже принимать участие в том или Ином виде для написания или

252: Валидации, проверки сценарного тестирования. Ну, как вы видите, на экране здесь все описано по-русски, что должно произойти, куда должно нажаться, в какое поле надо, какие данные ввести здесь, ну как бы достаточно понятно. И этот язык, он ближе к бизнесу.

253: Потому что они могут посмотреть и понять, что здесь происходит. Ну, если захотят, если не захотят, то никто не сможет этого сделать. Также авто, помимо тестирования, позволяет на основании вот этих сценариев генерить инструкции или даже

254: Которые, допустим, у нас есть новый функционал, мы там написали там новую кнопку в документе, который что-то полезное делает. Мы написали сценарный тест, который проверяет эту пользу, что она это делает. А потом ещё на основании этого сценарного теста можно записать либо инструкцию, ну как там в формате какого-нибудь там

255: Красивым, читабельным, либо в видео инструкцию, где 1 эска запишет все действия подряд, нарисует красивые стрелочки, куда надо нажать какие-то комментарии дать и даже с помощью яндекс алисы это дело озвучить. И у нас по сути сгенери,

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

257: Потому что не нужно там писать много логики, его нужно просто настроить и запустить, что будет происходить. У нас будут открываться по списку все формы, которые у нас есть в текущей конфигурации, будут открываться и ожидаться, что она не сломалась. Ну, допустим, после

258: Давление там при открытии там где-то развалится, у нас исключение вывалится. Мы это, эту историю можем отловить с помощью дымовых Тестов. Также можно считать дымовыми, допустим, создание нового справочника, его запись, либо

259: Запись уже существующего справочника. Если вдруг что-то сломалось при записи, то домовый это тесты выявят и там просигнализируют нужным людям, что надо че то перепроверить. Вот это не всегда бывает удобно, потому что на

260: Больших конфигурациях объектов много, форм у них много, и они могут достаточно долго крутиться. Вот. И иногда ещё бывают ложные срабатывания. Ну, у меня по опыту, последний раз было так, то, что у меня чаще были ложные срабатывания, чем реально дымовые тесты что-то выявляли, что такое ложное срабатывание у нас есть конфигура.

261: 1 с. Ну, например, бухгалтерия. Мы поставили новый релиз, запустили дымовые тесты, они упали, а потому что добавилась какая-нибудь новая обработка. Либо общая форма, которую, в принципе, она не подразумевает, чтобы её открывали. Вот просто вот так интерактивно она там вспомогательная. Для чего?

262: Будет, была нужна, либо должна открываться с какими-то хитрыми параметрами. Вот. А мы её попытались просто открыть тестами. Она, конечно же, упала, на сказать, я там, я не работаю интерактивно вот так вот и упала. И мы это отловили, стали разбираться, что за форма.

263: Чего и поняли то, что нам её не нужно тестировать, мы её добавляем в исключения. Вот. И чаще у меня были такие истории. То, что появляется что-то новое, что надо добавлять в исключения, чем мы что-то Ломали. Так что нам домовые это дело выявили. Но опять же это мой личный опыт. У кого-то может быть

264: Другому тесты нужны, но я считаю, что их не нужно крутить на вот постоянно, только там, на какие-нибудь большие релизы, изменения и так далее. Почему? Ну, помимо того, что они бывают ложно положительные, а ещё они могут достаточно долго работать в зависимости от размера конфигурации, там

265: Железо и количество форм это может крутить там 2 3 часа, пока все не проверит.

266: Так, и нагрузочное тестирование, как я говорил, это самое дорогое, потому что нужно иметь копию рабочего железа и на нём что-то крутить, как это делается с помощью, там, той же vanessa, либо какого-нибудь тест центра, либо каких-то других инструментов, которые

267: Запускать в параллель 1 эску много раз и вызывать, ну, эмулировать действия пользователя с какими-то там операциями, создавать документы, записывать, проводить новую номенклатуру, завести вот какие-то такие сценарии в параллель.

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

269: Часто ли это надо делать? Я считаю, нет. Ну, во первых, потому что дорого это, чтобы что-то релевантное получить, надо это вообще там сутки покрутить, наверное, и потом посмотреть нагрузку и сравнить её с тем, что у нас на проде, например, да, во вторых, надо иметь копию.

270: Ну, либо плюс минус релевантную конфигурацию сервера, железа и того, и того же. Ну, чтобы можно было как-то это дело соотносить. Ну, дополнительно, кроме всего прочего, нужно откуда-то запускать тесты там, под это, там тоже ресурсы нужны. Вот. А видите, как много всего.

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

272: То, ну, надо как бы проверить, плюс минус, работают ли у нас те же самые пользовательские операции с той же скоростью, как они работают, допустим, на другой свобод, либо мы просто на другой сервер переезжаем. Ну, купили новый, да, и надо проверить, как мы правильно, неправильно настроили.

273: И там все ли там хорошо. И вот тоже можно вот это дело прогнать, чтобы убедиться, что мы туда можем ехать, и мы по производительности не потеряем, н, каких-то таких моментах. Либо мы там долго не обновлялись, какая-нибудь база, которая не требует постоянного обновления там с учётом там

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

275: Вот в каких-то таких переходных историях, наверное, имеет смысл постоянно, ну, как-то её покрутить. А если, ну, конечно, если есть ресурсы, деньги, это можно там на каждый релиз и на каждую фичу. Но, как правило, я был там, где

276: Это было бы непозволительной роскошью. Так, ещё раз давайте зафиналимся по поводу тестирования. У нас есть несколько видов тестирования. У нас есть автомен для тестирования сценарного кнопка. Нажималка у нас есть.

277: Для модульного тестирования, чтобы именно кодом какие-то определённые процедуры, функции проверять и их взаимодействие. У нас есть тест центр, который я немножко заговорил, он больше подходит для нагрузочного тестирования. Вот ещё у нас есть джеметр и postman, это

278: По которое, ну, давайте скажем так, оно не про 1 с, оно, про то, что мы могли дёргать какие-нибудь аштипи, эндпоинты. Ну, например, у нас есть 1 эска, в которой есть http, сервис, который какие-то, да.

279: Отдаёт, да, вот. И нам нужно его протестировать, как он работает. И тоже самое нагрузочное тестирование. Мы ожидаем, что у нас он будет дёргаться там 850 раз в час.

280: Параллельно десятью пользователями. И нам надо посмотреть, как оно будет себя вести, допустим, на иисе, на апаче, либо ещё как-нибудь и с помощью там постмана, либо джеметра. Мы можем сделать определённые настройки, которые будут дёргать те или иные поинты в 1 Эске и смотреть-ка

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

282: Концу. И я поговорю про вспомогательные инструменты, которые связаны с релизами и со всеми предыдущими шагами. Как я уже говорил, мы, у нас есть инструменты для тестирования, там автомейшн икс юнит и так далее. То есть это некоторый код

283: Обработки либо расширения, которые позволяют что-то делать, тестировать, проверять. Но мы же не будем сами руками каждый раз это дело проверять. Все эти инструменты имеют возможность, как бы запускать их с использованием интерфейса команд.

284: Строки, то есть мы можем написать команду, там тот же самый, передать ему определённые параметры, и он запустит 1 с предприятий и прогонит там тесты x юнита, либо прогонит тесты с автомейшен и в каком-то формате результаты этих

285: Сохранить. А раз мы можем написать команду, значит, мы можем написать скрипт или батник, либо ещё что-то такое, которое будет на это дело запускать. Ну раз мы написали эти батники, ну, запускать их руками уже какой-то прям.

286: Годное дело, грешное, и это дело тоже можно автоматизировать. Соответственно, эти скрипты можно как-то запускать на автомате. И вот сейчас мы переходим к следующему инструменту, пока мы переходим. Вот ссылка на наш курс.

287: Девопса здесь есть промокод и скидка 5%. Вот. Соответственно, на девопсе мы вот все эти штуки, о которых сейчас я вам рассказываю, даже больше тоже в том или Ином виде затрагиваем и про них рассказываем. Так, двигаемся дальше.

288: Автоматизированный запуск инструментов для автоматизированного запуска много. Самый простой это какой-нибудь виндовый шедулер, который умеет по расписанию запускать батники. Но это не очень удобно, это прошлый век и так получилось.

289: То, что инструментов много, всякие там тревис, джарвис, какие-то ещё были тимсити, вообще их много, но так исторически сложилось. То, что около 1 эс, 1 из самых распространённых таких автоматизаторов, это

290: Это, так сказать, тоже программный продукт, целая платформа для того, чтобы автоматизировать всевозможную рутину и

291: Он написан на джаву, он с открытым исходным кодом, и он очень хорошо плагини, ируется всевозможными плагинами и расширяется. Он имеет клиент серверную архитектуру. Что это значит у нас, если мы хотим эту штуку развернуть, у нас

292: Отдельный сервер, на котором крутится сам дженкис, это некоторое приложение с веб интерфейсом, в которое можно аутентифицироваться, залогиниться и там можно настраивать выполнение тех или иных скриптов, а где они будут выполняться, они будут

293: Не на самом сервере jenkins, они будут выполняться на его агентах, то есть, например, сам jenkins может крутиться где-то далеко в контейнере, где нету 1 эски, нету платформы, лицензии, там вообще ничего нет, там просто java и.

294: И сам этот jenkins сервер, а на нашем разработческому сервере, где у нас есть платформа 1 эс, где у нас есть лицензия, всякие Ван скрипты Ван, а у нас это уже все есть непосредственно на нашем сервере, ну или тестовом, ну, на каком-то нашем сервере.

295: У нас 1 эсников, он нам выделен. Мы там можем понять, поднять, запустить агента, который подключится к серверу, и сервер может на нём запускать всевозможные скрипты. Что это нам позволяет. Мы можем либо по расписанию, либо по каким-то иным, другим триггерам.

296: Запускать все те инструменты, о которых я говорил вам ранее. Ну, например, каждый раз по расписанию. Раз в час он оттуда может запускать бит синк, который будет подключаться к хранилищу, которое доступно на этом сервере у нас на 1 сном и

297: Перегружать наше хранилище конфигурации куда-нибудь в гид, соответственно, также по этим триггерам мы можем запускать всевозможные тесты я x юнита автомейшн запускать sonar после того, как у нас запустился.

298: Geek, да, и делать ещё какие-то проверки, стат анализа, все это можно делать вот вот в такой достаточно простой архитектуре, когда у нас где-то там вот оркестратор вот этих всех задач, а конкретные задачи выполняются на том или Ином нашем 1 сном сервере.

299: Запускаться он может эти скрипты по разным триггерам, как я уже сказал, может по расписанию каждый час, либо он может следить за изменениями в каком-нибудь репозитории на каждое изменение делать запуск того, допустим, может смотреть то, что у нас на ветке дэ что-то поменял.

300: Запустить тесты. Также у него есть рестапи, и мы его можем откуда угодно дёргать и запускать любые задачи. Ну просто имея токен да, доступа к той или иной задаче, задачи могут быть связаны не только там, что-то 1 запустить да, выгрузить, а там

301: Прям целые пайплайны, то есть целый конвейер запустить 1, если оно не упало, запустить другое, 3. И так мы можем целый конвейер построить, который будет получать, допустим, исходники из git позитория, конвертировать их. Да, давайте исходники.

302: У нас в формате едт, чтобы было посложнее, получил исходники в формате едт, сконвертировал их в исходник в формате конфигуратора, собрал и загрузил в нужную базу и запустил там, допустим, сценарные тесты авто тесты прогнались, сформировался

303: Отчёт, и он этот отчёт приложил. Допустим, валю классно. Мы ничего не сделали, а у нас столько операций прошло, и мы можем видеть отчёт о том, что у нас те или иные тесты упали, либо не упали. А параллельно ещё проверка сонара закончилась, и она тоже прилепила свой отчёт. Вот. И здесь не

304: Написал код.

305: Также там есть возможные системы идентификации. То есть, ну, допустим, пока у нас штуки не падают, все хорошо. Если вдруг где то что-то упало, мы, соответственно, можем либо в почту, либо в какой-нибудь там мессенджер любой прикрутить и будут лететь уведомления. Здесь вот упа.

306: Тесты, либо ещё что-то такое. Вот помимо всех красивых Тестов можно автоматизировать выкатку релиза ну то есть допустим это уже будет запускаться не по расписанию, а в какой-то отдельно выбран

307: Или даже просто руками. То есть у нас вот мы полностью подготовили релиз, у нас уже готовый техник, и там при нажатии кнопочки можно визуально сделать несколько Шагов такого так называемого диплой тупро, да, то есть запустится у нас сначала

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

309: Грузить туда технику, потом применить обновление, обновление, ну которые бочонок и потом уже обновление, допустим, даже эти бспн колёсики уже в режиме предприятия. Все это у нас прошло, не упало. Потом мы снимаем блокировку с базы и пользователи дальше могут заходить все это по нажатию 1 кнопочки.

310: А можно отслеживать в

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

312: Хранить в том же репозитории рядом с нашей конфигурацией, либо в любом отдельном репозитории. Если у нас вот этот вот скрипт сборки, он универсальный, подходит для разных конфигураций, можно в отдельном, либо в том же в гите хранить. И при запуске Денис будет не

313: Грубо говоря, не себя, а будет качать его с нужного репозитория и запускать. И в таком случае наша инфраструктура сборки вся идиная, она тоже как код, хранится в репозитории, и мы её историю отслеживаем.

314: Так, это 1 инструмент. Сейчас я буквально на секунду поставлю паузу, сделаю глоток.

315: И 2 инструмент я его обобщил, потому что их есть несколько, они все примерно похожи по функционалу, но различаются по синтаксису это так называемые гид сервера это git gitlab ну я часть.

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

317: Дополнительно они ещё могут работать с исходным кодом и реагировать на изменения. То есть там можно, помимо всего прочего, ещё вот эти триггеры, допустим, как у нас меш, реквест открылся, мы хотим влить в ветку, develop

318: Нашу фичу, то там свои тестики запускаются, да? А после того, как мы влили, может запуститься другой скрипт, который соберёт и в какую-нибудь девелоп базу это разольёт, чтобы аналитики могли сразу посмотреть вот функционально. Плюс минус тоже са.

319: Другой синтаксис описания не как в дженкинсе у gitlab git флика они ну отличаются где-то ямлики с такой структурой, где-то с такой, но принцип один и тот же мы описываем шаги, которые должны происходить в тот или иной момент, а эти шаги, по сути, это.

320: Включённый тот же агент то есть не там где у нас это все запускается где тот же gitlab стоит у нас тот же наш сервер разработческий девелоперский либо называйте его как хотите он подключается как агент как исполнитель заданий и gitlab уже ему говорит давай выполни те самые тесты он их выпол.

321: Результат выполнения отображает обратно в рекламе.

322: Так и вот, соответственно, что если обобщить релизы и все предыдущее автоматизируется с помощью либо всевозможных шедулеров, удобный это jenkins, либо какой-то сиайсиди движок, который есть.

323: Том или Ином гид сервере, там git, флики гитлаб и их много. И, как правило, все вот эти скрипты, которые автоматизируются, строятся вокруг, либо ванесса раннера. Ну, потому что я уже сказал, это удобный швейцарский нож, чтобы

324: Вот эту всю нашу скриптовую инфраструктуру около запуска 1 с тем или иным способом, чтобы это было удобнее. И едт Клин, ну, для конвертации едт исходников из 1 формата в другой.

325: Вот это нужно, как и для релизов, также и для тестирования и предыдущих Шагов в том или Ином виде можно использовать. Так мы ещё не закончили. Дальше немножечко я расскажу вам про курс. У нас тающие скидки 15% до 27.

326: 12. И если берете 2 или 3 курса, то там прогрессия у нас увеличивается по поводу скидки. Вот эта ссылочка на вступительное тестирование для того, чтобы попасть на курс devops 1 эс. Так.

327: И двигаемся дальше. Программа курса следующая у нас. Мы вот рассказываем про подготовку разработки, какие они бывают там едт не едт линукс не линукс, контейнер, не контейнер, отдельно обсуждаются всевоз.

328: Сценарий обмена данными, как они пристраиваются рядом, в принципе, с культурой девопса, как они там мониторятся, настраиваются и так далее. Вот подождите, опять же также у нас разбирается все.

329: Возможные истории, связанные с Юдт с применением спра, всевозможные брокеры сообщений и прочие такие событийные истории, связанные там кролики, кафки и так далее. Вот мониторинг производительности, где

330: И как чего настраивать, как это мониторить, как использовать те или иные виды автотестов, как это встраивается в ccd и какими механизмами это можно скриптовать. Вот, и в конце всего этого прочего у нас будет проектная рабо.

331: Проектную работу. Отчасти вы можете выбрать какую-то свою тему. Либо преподаватели курса там вам помогут, либо руководитель курса. Кстати о преподавателях и руководителя. У нас Сергей Бывальцев на этом курсе преподаватели это ваш покорный слуга.

332: Никита Иванченко, Дмитрий Малахов и Юрий Пасхин. Мы все занимаемся немножко разным на этом курсе. То есть курс модульный где-то в каких-то модулях, какие-то блоки, связанные с тем или иным инструментом. Вот все, что связано там с автоматизацией, автотестами и

333: Вот такой вот постскрипт девопсятины там я коллеги по другим направлениям.

334: Так, обучение происходит, ну примерно вот как мы сейчас с вами, то есть у нас начинается онлайн урок, я что-то рассказываю. Сейчас я пришёл к тому, что на открытых вебинарах я ничего экран не демонстрирую и код не пишу, и ничего не делаю, но

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

336: Чат. И там я обязательно включусь и постараюсь помочь. А че там не получается или что было непонятно. Все записи доступны после завершения курса.

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

338: Можно там попросить помощи, либо просто получить обязательно обратную связь относительно того, как домашнее задание было выполнено. Вот. И программа курса, ну, от курса к курсу постоянно пытаемся её обновлять, чтобы более менее актуализировать и успевать за тем,

339: Сейчас в мире происходит

340: Так, вроде вот так ссылка на курс начинается совсем скоро, длится 4 месяца и вот QR-код, наверное, который приведёт на непосредственно курс либо на тестовое задание, я уже не помню.

341: Двигаемся дальше. Подведём итоги занятия. Теперь вы знаете, и я надеюсь, что я вас познакомил с инструментарием, который автоматизирует проверку кода, автоматизирует всевозможные способы тестирования и сборки приложений. В связи с этим вы

342: Знаете, и знакомы теперь с инструментами, которые сейчас в том или Ином виде применяются. Если вы никогда это не применяли, вы хотя бы будете знать, с чего начать, куда идти, какие инструменты пробовать в 1 и какие во 2 очередь для того,

343: Чтобы прийти к какой-то автоматизации вашей команды разработки, ссылка на всевозможные наши каналы в telegram и наверное да, в telegram там с новостями и со всем прочим сейчас.

344: Я скину ссылочку на опрос и призываю сейчас.

345: Пройти этот опрос, если вдруг вам что-то, да где ж у меня вот ссылка на опрос. Ага, копировать ссылку. Если вам что-то не понравилось в моём рассказе, обязательно об этом сообщите. Можете поставить, я не знаю, там либо минус, либо там двойку.

346: Ну, напишите, че было не так, чтобы я получил от вас развивающую обратную связь и в следующий раз сделал что-то лучше.

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

348: Быстренько сейчас крутану чат, пока была более пустой микрофон. Вдруг все-таки были какие-то вопросы. Ага. Так вопросов не было. Что писали коллеги? Хочу послушать опыт работки гид и 1 с их

349: В команде гид + 1 s. Да вот про это я рассказал, значит вариантов 2 с 1 стороны простой, сложный и дорогой ничуть дорогой по железу это сразу брать едт и пробовать что-то делать, если у вас в.

350: Ведении несколько конфигураций. Какая-то из них относительно маленькая. Ну в количестве объектов, да, то можно попробовать на ней едт. Остался ли сейчас инструмент едт ринг. По моему, едт ринг деприкейтнули.

351: В последней версии ты его вообще выпилили. Так что, наверное, скорее всего, нет, чем да, это был вопрос от кирилла. Большое спасибо. Было познавательно пишет Олег. Отличная подача. Спасибо, пишет Филипп, пишет. Ну,

352: Я я прочитаю Филипп я не могу тяжело прочитать твой ник вот и как я уже говорил да это 1 вариант либо 2 вариант по чуть чуть это поставить Гитин немножко выгружать просто чтобы ребята смотрели куда-нибудь в gitlab и научились туда смотреть.

353: Там истории кодревью. Вот, и для ловких и умелых, если мы прям ни в какую не хотим в едт, вот можно заскриптовать я каким-нибудь условным раннером, чтобы исходники выгружались, загружались поработать так это не просто с точки зрения смены платформы и

354: Артефактов, но это возможно, я так на протяжении, наверное, лет 4 работал какое-то время назад. Так Кирилл пишет, как ed разрулит конфликты при затягивании ветки из репозитория в едт есть механизм похожий

355: На сравнение и объединение, где она там разворачивает дерево по объектно и при конфликтах она там также примерно как в конфигураторе показывает было, что пришло и что в итоге мы хотим видеть вот это можно делать.

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

357: Вещи, связанные с x, с метаданными, то есть, допустим, разработчик 1 добавил свои метаданные разработчик 2 добавил корень свои метаданные, они как будто бы конфликтуют, ну потому что они в 1 и ту же строчку добавляются, а по факту они просто.

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

359: Можно там конфликты на формах с эксемельки её тоже более менее нормально разбираются руками это плохо очень разбирается в xml то есть это там прям тяжело так я вижу новые вопросы.

360: Так, Никита, спасибо большое. Слышал про множество новых для меня инструментов. Есть чего поизучать, какие варианты есть. Доставки, конфигурации из гип на прод. Вариантов много. Я обычно как делаю, когда

361: Я на какой-то ветке, на мастере, у меня вот я уже знаю, вот эта сборка точно хорошая, она уже оттестирована, я из неё в любое там рабочее время могу собрать артефакт, то есть подго из собрать из исходников техник.

362: В нём уверены, потому что он до этого был оттестирован и уже его какое-то время хранить и на prod его выкатывать ну когда мне бизнес позволяет это делать, вот иногда бывает так-то, что за выкатку на прод отвечают.

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

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

365: Работают все сидят во всевозможных местах и хорошо проводят время, ну, с точки зрения наших пользователей, да, а мы запускаем скрипт, который берет и выкатывает этот ник на прод, ну, то с отключением пользователь копирование, а вот со всеми этими делами, так,

366: И очерёдность строк, так я понимаю, ему не сильно важна это, наверное, к вопросу по поводу Гита и нет, на самом деле очерёдность строк важна и конфигуратору.

367: Едт. Ну то есть метаданные у нас тоже в каком-то порядке, да, там новые документы появляются, они снизу, там не только документы, там всякие объекты, они снизу добавляются. И в едт есть кнопочка вот для вот венеровны вот этих вот объектов, которые мы добавляем.

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

369: Вроде бы как-то, ну, абсурдно звучит, но на самом деле это удобно. Когда вот он сортирует эти методанные, он также и сортирует их в эксемель. И, соответственно, там конфликтов минимальный получается. То есть не все снизу добавляется в конец, а вот по алфавиту.

370: И это тоже какие-то конфликты в эксельках очень помогает решать так это просто праздник какой-то. Твёрдая пятёрка с плюсом за лекцию. Это что такое, Алексей, спасибо тебе от души. Так, очерёдность рок вопрос про конфликты дт, например, внизу модуля добавлены разные процедуры, разные программ.

371: Мистами.

372: Нет, ну.

373: Нет, там, там, в едт конфликта не будет, он умеет разбирать исходный код с учётом структуры модуля, да, то есть он увидит то, что тут новая процедура и тут новая процедура, они по именам не пересекаются. Если мы это будем мерить условно через, через консоль Гита, либо через

374: Какой-то другой инструмент, который не знает про 1 эс, то он увидит то, что у нас просто строки поменялись, да, и у нас там конфликт, но если мы этот конфликт увидели в едт, то есть 1 разработчик добавил процедуру посчитать ставку ндс, a2 разработчик

375: Процедуру посчитать ставку ндфл, то это будут 2 разных метода, и дт увидит то, что они 2 разных, да, они оба добавляются. То есть у них названия не пересекаются.

376: Так, в едт можно одновременно редактировать основную конфигурацию и расширение или это разные проекты, можно внутри 1 ворспейса, внутри 1 проекта работать и с конфигурацией, и с расширением, и ещё скажу больше, даже с какими-то отчётами и обработками. Это все

377: Можно хранить в рамках 1 репозитория и, соответственно, что это очень удобно у нас это есть основная конфигурация, у нас есть расширение я x юнит, которое относится к этой конфигурации, там тесты, которые относятся к этой конфигурации, и если я пишу какую-то фичу в основной конфигурации, у меня есть код реалии.

378: Какую-то новую функциональность рядом в рамках этой же ветки я могу написать код в екс юнити в расширении, который тестирует этот метод. И когда я буду делать, открывать Мереке в какую-нибудь там условно релизную ветку, у меня там

379: Будет сразу видно код, который я написал, и тесты к этому коду. И когда кто-то делает код, он сразу видит. Ага, вот Никита молодец. Он не только вот написал, он ещё и тестами это покрыл. И может тут же ещё и тесты.

380: Так что, да, можно вот в едт работать сразу в рамках 1 проекта 1 репозитория, и с расширением, и с основной конфигурацией, и с этим самым внешним отчёт обработка даже больше. Можно несколько конфигураций туда засунуть. Это я, ну, мне сложно.

381: Сценарий. Зачем можно в рамках 1 репозитория проекта работать с несколькими конфигурациями? Ну там это тоже можно

382: Так все вроде как ответил.

383: Ответил, ответил так, коллеги, я сейчас ставлю голос на паузу, делаю глоток воды, горло отдыхает. Если и про себя считаю до 30 полминутки, если больше вопросов не будет, мы тогда с вами расходимся, и вы меня отпускаете. Я

384: Вас отпускаю. Если ещё будут вопросы, я обязательно вам отвечу.

385: Так, коллеги пишут мне слова благодарности очень тёплые. Мне это очень приятно. Вопросов я пока больше новых не вижу, поэтому я благодарю всех, кто пришёл, что-то написал, со мной пообщался, я не звучал.

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

387: Хорошего окончания этого.