Казалось бы, доклад про устроение DevOps должен быть про настройку Дженкинса, но нет!
Этот доклад для тех, кто понимает, что DevOps — это история про культуру, коллаборацию и общение, но не очень представляет, как будучи скромным исполнителем или тимлидом, повлиять на целый энтерпрайз, и сдвинуть организацию в сторону DevOps.
Барух расскажет какими методами можно воспользоваться для влияния на stake–holder-ов, что кому говорить, как мотивировать, и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе будут обозрены все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.
Барух Садогурский (a.k.a. JBaruch) — Head of DevOps Advocacy и Developer Advocate в компании JFrog. Больше всего любит рассказывать о технологиях — то есть просто поболтать любит, но человек, говорящий о технологиях, имеет умный вид, да и 18 лет опыта в сфере высоких технологий никуда не делись. Когда он не выступает (ну, или не летит к месту следующего выступления), то изучает технологии, людей и то, как они работают, точнее, не работают вместе. Барух — соавтор книги «Liquid Software», CNCF ambassador и профессиональный спикер по таким темам, как DevOps, DevSecOps, Go, Java и др. Он регулярно выступает на таких известных конференциях, как Joker, JPoint, DevOops, Heisenbug, DockerCon, GopherCon, Devoxx, DevOps Days, OSCON, Qcon, JavaOne и др. Некоторые его доклады можно посмотреть здесь: jfrog.com/shownotes.
Леонид Игольник хорошо знаком и с разработкой, и с управлением, и с администрированием масштабных проектов. До недавней продажи SignalFx в Splunk он занимал должность Executive Vice President of Engineering в SignalFx. Всю свою карьеру он занимается онлайн-приложениями, начав её в одном из первых интернет-провайдеров Израиля. Первый опыт работы с масштабными приложениями на Java у него произошёл в 2002-м, когда он работал во втором по величине на тот момент доменном регистраторе.
Еще одна неделя с Ютестом! По многочисленным просьбам, сегодня будем разбирать поиск багов на примере тестирования реального проекта.
Показывать примеры тестирования публично достаточно опасно, т.к. часто нужно подписывать — NDE (Соглашение о Неразглашении). Я расскажу об этом соглашении и почему не следует рассказывать о деталях проектов, которые вы выполняете. Тем не менее, я покажу реальный пример из Академии, исключая имя и подробности о заказчике.
В нашей работе консультантами по DevOps, мы часто сталкиваемся с вопросом клиентов, из чего же, собственно, состоит DevOps. Абривиатура CAMS плохо подходит для того, чтобы продавать, потому что никто не купит культуру или Knowlage Sharing. Мы рекомендуем нашим клиентам внедрять следующие практики: Infrastructure As a Code, Continuous Delivery, Continuous Monitoring, Automated Testing и Test Data Management. В докладе я расскажу, что мы подразумеваем под этим, а также про некоторые кейсы из нашей работы с крупными российскими компаниями.
Приглашаем на DevOpsConf live! — профессиональную конференцию по интеграции процессов разработки, тестирования и эксплуатации
29 -30 сентября и 6-7 октября 2020
Подробности и билеты bit.ly/2NGn8Tt
— DevOpsConf Russia 2018
Про DevOps есть очень много мифов, мифы эти связаны с искажениями информации, часто про DevOps говорят люди без реального опыта работы в технологических компаниях с непрерывной поставкой или говорят для получения собственной выгоды какие-то искаженные вещи.
Между тем, DevOps служит конкретной цели, решает конкретные задачи. Мы поговорим с вами о том, какие задачи DevOps решает и как решает, какие практики есть в DevOps и почему именно они, что такое культура в DevOps и является ли эта культура более “культурной”. Какие проблемы есть с точки зрения организации и командного взаимодействия.
…
— Нашли ошибку в видео? Пишите нам на support@ontico.ru
В этом выпуске у меня в гостях, senior devops engineer — Никита. Никита рассказал, как он стал из обычного системного администратора ведущим девопс инженером.
Мы разобрались в том, что же такое девопс и какие его области ответственности, какие инструменты используются девопсами, что такое докер и continuous integration.
Кроме того у Никиты богатый предпринимательский опыт и за плечами годы работы в big data.
И конечно, я задал сакральный вопрос, которой интересует большинство людей — сколько же зарабатывают девопсы.
0:00 – вступление Сергея Немчинского
00:27 – кто еще считает, что Null возвращать нельзя?
02:02 – почему нельзя возвращать NULL: обработка ошибок вручную
04:48 – почему нельзя возвращать NULL: неоднозначное понимание
06:16 – реклама
07:22 – почему нельзя возвращать NULL: нарушение мышления программиста, нагромождение кода
10:38 – почему нельзя возвращать NULL: медленный провал, затруднение поддержки системы
13:31 – история про индусов
15:13 – использование Null в изменяемых и незавершенных объектах
17:15 – как же тогда работать?
Это финальный выпуск WIN WIN SHOW. На протяжении всего сезона ребята участвовали в разного рода вызовах.
Каждый делал что-то впервые, чтобы проявить вcе свои качества предпринимателя в условно лабораторных условиях.
Если ты смотришь с первого выпуска, надеемся, к этому времени сможешь ответить на вопросы: как привлечь инвестиции в бизнес, как убедить инвестора, как начать бизнес без денег.
Понятно, что в формате шоу тебе как зрителю невозможно дать подробную пошаговую инструкцию по привлечению денег для бизнеса.
Но задача была в том, чтобы показать, сколько денег и в какие бизнесы готовы инвестировать, а главное — каким людям готовы помогать инвестициями и что важно для инвестора при принятии решения.
Если ты внимательно анализировал(а), то точно поймешь все, что мы хотели донести. Или просто получишь удовольствие от просмотра, мы на это надеемся.
Пиши ниже, что думаешь об этом шоу, будет интересно прочитать любые мысли.
P. S. Мы не прощаемся!
Также все видео по порядку есть в плейлисте, им удобно делиться с друзьями, чтобы не путаться с очередностью серий: www.youtube.com/watch?v=QR70M6sszWU
Друзья, в этом видео я расскажу вам о том, что такое Git, зачем он нужен, как его использовать и как с его помощью оптимизировать и упростить работу в команде. Мы поговорим обо всех особенностях использования этого инструмента и я наглядно покажу как с ним работать.
Что такое git?
Git — это система контроля версий, а если сказать простым языком то это программа, инструмент, которая позволяет нам фиксировать наши изменения в коде, а также благодаря этой фиксации позволяет нескольким людям или даже командам вместе слажено и параллельно работать над каким-то программным продуктом.
Представьте что вы пишите программу и у вас есть какая-то функция, которая допустим сохраняет информацию информацию о пользователе в базу данных, и для этого сохранения вам естественно нужна логика которая собственно это сохранение будет делать. Вот вы написали код, все круто все работает. Как сделать своего рода сохранение как в компьютерной игре которое сможет зафиксировать прогресс?
Git — это как раз такая программа, такая система, которая позволяет эти сохранения создавать и потом управлять ими, менять, возвращаться к ним, удалять и переписывать их, такая фиксация в терминах Git-а называется `commit`
Проще всего гит представлять по аналогии либо с компьютерной игрой и ее сохранениями либо с таким роботом-фотографом, который в любой момент который вы ему скажете сделает так сказать фотографию ваших файлов с которыми вы работаете, зафиксирует их состояние на текущий момент, и затем любой момент может вам сказать поменялось ли что-то в этих файлов с момента прошлой «фиксации».
Git собственно так и делает, вы говорите ему команду, он запоминает состояние ваших файлов на текущий момент присваивая ему специальный номер вот это снимка, там называемый `commit hash`.
Commit hash — набор символов которые уникально идентифицируют сохранение состояния файлов в конкретный момент времени;
Что такое ветки в гите и как их использовать?
В git также используется так называемая система веток, представьте себе что ветка, так называемая branch — это маршрут по которому едет поезд, а каждая его остановка, сохранение состояния это коммит. То есть когда мы начинаем разрабатывать какую-то задачу, пишем код нам нужно идти с точки А в точку Б, у нас скажем пустой файл, а потом постепенно наш код начинает эволюционировать и он со временем начинает что-то внятное делать.
Так вот этот процесс разработки можно представить по той же аналогии с поездом, поездвыезжает с точки А и ему нужно доехать до точки Б, и этот маршрут он будет ехать по своему пути (в нашем случае это и будет ветка нашего git), а также по пути ему надо останавливаться чтобы фиксировать свой прогресс по маршруту, это и будут коммиты в нашем случае, то есть мы пишем код в рамках ветки и делаем коммиты, для того чтобы сохранять наш прогресс внутри метки.
Как его используют команды?
Как такой подход позволяет нам распараллелить работу разных людей и команд и сделать их более продуктивными? Все дело в том что когда мы работаем над каким-то проектом и нескольоко людей пишут код они во 1 могут одновременно менять одни и те же файлы.
Так вот фишка гита в том что каждый разработчик может сам себе создать такую ветку, уникальный маршрут поезда на пути которого будут свои уникальные остановки, то есть свои уникальные коммиты этого разработчика, и эта ветка она будет скажем так принадлежать одному человеку и там он будет фиксировать все свои изменения, делать коммиты.
И все сводится к достаточно простой логике, у нас есть какой-то код который нам надо написать, мы сделали новую ветку, по пути того как мы разрабатываем мы в этом ветке делаем коммиты чтобы зафиксировать изменения, как только мы понимаем что у нас все готово, нам нужно объединится с другими разработчиками, скажем так сделать так чтобы наши изменения ехали по общему маршруту, то мы просто сливаем все наши коммиты из нашей ветки в общую. По аналогии с поездами можно представить что у нас есть какая-то главный поездной маршрут в котором есть все наши остановки, коммиты из всех веток. Таким образом все довольно просто, сделали ветку, написали код попутно фиксируя изменения коммитами, после того как закончили, слили все наши изменения в общую ветку чтобы эти коммиты, эти изменения были доступны всем другим разработчикам.
00:00 Начало
1:03 — Git — что это?
2:52 — Что такое Git commit
4:09 — Ветки или «branch» что это такое?
5:27 — Как команды используют Git?
7:49 — Как применять Git в работе. Практика.
7:57 — Новый репозиторий. (Git init)
9:17 — Создание файла и коммита. (Git commit)
11:46 — Сохранение файлов (Git commit -m)
12:46 — Как работают с ветками и какими они бывают.
14:51 — Создание develop ветки, и ветки для работы ( Git checkout -b feature)
17:06 — Как новый файл добавляется в Git
19:39 — Откат к коммиту (Git reset)
20:44 — Слив на одну ветку (Git merge)
На машина по главному острову архипелага Окинава. Дороги и автомобили. Американская военная база и как к ней относятся местные жители? Почему Окинава не такая популярная как Гавайи и чего там не хватает туристу?
**********
Станьте спонсором канала и получите возможность смотреть видео первым, смотреть стримы в записи и задавать вопросы и получить доступ к экслюзивному контенту. www.youtube.com/channel/UC1AhzkpXFX6_kAc7niTcc3w/join
**********
Влог о Японии — Все что вы хотели знать о жизни в Японии