Pull to refresh

Comments 13

Очень интересно, спасибо, буду ждать публикации ваших продуктов, в особенности интересно посмотреть на CrossBuilder
Спасибо! Постараемся довести их до ума в следующем году. PS/ Надо же, я удивился увидев, что когда то читал и использовал вашу статью про гугл-апи – она была полезной.
Рад, что статья помогла. Загляните в мой блог, может и там что найдете ;)

OMFG! и ведь эти люди на полном серьёзе уверены, что у них DevOps, CI и даже CD...

Ребята, вы решили заопенсорсить несколько своих тулов, это похвально, спору нет.
Но при этом вешать туда шильдик Open DevOps Community, и я цитирую: «Tools, best practices and examples for the open community of automation engineers.» это перебор.
Я удивился, увидев такой ваш комментарий. Возможно, возникло какое-то недопонимание сути статьи. Более того, когда-то я с удовольствием прочитал вашу статью про девопс. Ещё раз перечитав её, я не нашёл противоречия с нашей: у нас нет ни «отдела девопс из 35 человек», мы не «нанимаем сисадминов с кучей доп.компетенций», и в то же время мы и пытаемся в нашей большой компании создать и внедрять «простые работающие решения». Кроме того, мы уже 4й год, также как и описывали вы в своей статье, работаем в направлении взаимодействия между разработчиками, тестировщиками и ИТ-службами. За что отвечает наша служба автоматизации и какие на неё возложены роли, мы честно и подробно написали в 3-4-5 абзацах статьи.

Что касается названия «Open DevOps Community» и всего прочего – да, частично согласен, возможно мы немного поспешили с его анонсом. Но с другой стороны – где нашим парням выкладывать свой код? Кроме того, опять же, почему «Tools, best practices and examples for the open community of automation engineers» — это перебор? Если мы именно это и хотим сделать в итоге, то зачем писать что то другое? А как бы вы предложили назвать? Кроме того, как я и написал в статье, проект фактически только стартовал и не претендует на мега-систему девопса и истину в последней инстанции. Будем развиваться потихоньку.
1. Я не автор статьи, это перевод. Это не к тому, что я с ней не согласен, а просто мне режет слух «ваша статья».
2. Я не критикую по теме DevOps в вашей компании, потому что это не мое дело и потому что, если результат положительный, какая разница.
3. Почему так резко отозвался на тему названия на github? Просто, честно говоря, каждый день вижу появление этих «всероссийских» devops сообществ, а толку нет почти. А description намекает, что для вас DevOps = automation.

А так, призываю еще поучаствовать в инициативе Саши Титова devopsrussia.org
Он рассказывал о ней на DevOops Piter.
Зачем нужен TeamCity, если его функции может выполнять Gitlab?
Спасибо за вопрос. Возможно я повторюсь, но мне кажется, в статье я уже подробно ответил на него:

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

К этому могу добавить только то, что это был 2014 год (когда мы искали замену CI на базе TFS), а что-то вменяемое для CI на базе GitLab начинает появляться только сейчас. Мы тоже сейчас экспериментируем с GitLab-CI и переводом «простых» сборок на него, но TeamCity, всё-таки, сейчас гораздо приятнее внешне и мы хорошо отладили в нём масштабирование наших сборочных проектов. Можно долго спорить по этому поводу, но для больших многокомпонентных продуктов сейчас GitLab-CI ещё не очень удобен в эксплуатации. Но мы не теряем надежды на переезд в GitLab-CI и, кроме того, с помощью инструмента CrossBuilder мы надеемся сохранить и перенести все наши скриптовые наработки для TeamCity-метараннеров (которых у нас уже несколько сотен) в GitLab-CI.
Можете подробней описать об использовании Kubernetes. Используете ли вы его в production или только в dev и test среде? какова стабильность работы? и т.п.
К сожалению, сейчас прокомментировать что-то по сценариям использования Kubernetes для DevOps-задач я не могу, т.к. активно он в нашей команде не применяется. Возможно, в статье нужно было уточнить, что Kubernetes используется в разработке (dev+test) некоторых наших продуктов, которым мы помогаем, но не непосредственно нами. Подробнее про эти продукты я пока рассказать не могу.
Ребят, статья прекрасная. Пару вопросов: Почему перепрыгивали с TFS на TeamCity, а не на Jenkins, чем он для вас оказался хуже (и оказался ли)? И исходя из вот такой вот записи
и Windows (2003-2016)
решил что у вас имеется legacy (может ошибаюсь). Но если всё же есть, то как вам его удается подружить с CI/CD, если оно писалось тогда, когда у вас еще DevOps не было и в помине? Спасибо.
Большое спасибо, за высокую оценку! Мы рады, что добавили свою копеечку в общее дело! Насчёт Jenkins. В 2014 году мы не стали рисковать пересаживаться на опен-сорс решения в виде Jenkins – в то время, нам показалось, что может быть множество проблем с обновлениями самого Jenkins, его поддержкой и многочисленных плагинов, которые нам были нужны. Также, в то время были не очень хорошие отзывы о нём со стороны инженеров. Которые работали с ним более плотно, а TeamCity очень хорошо себя показал на пилотных испытаниях проектов, продемонстрированных тем, кто принимал тогда решение о его использовании.

Насчёт легаси. Как и у всех достаточно крупных компаний, есть оно и у нас, но, что касается CI/CD инфраструктуры – его у нас минимально: из «старья» на поддержке остался только 1 сборочный сервер, со своей самописной CI-системой. Всё остальное было переведено на новые рельсы, описанные в статье. Сборочные сервера у нас имеются различных типов с различными ОС, это зависит от требований разработчиков, собирающих тот или иной модуль. На каждом из них стоит сборочный агент, поэтому проблем с их дружбой с текущей CI-системой не возникает.
Only those users with full accounts are able to leave comments. Log in, please.