Системы управления версиями *

Обнаружена новая критическая уязвимость CVE-2014-9390 в Git, позволяющая выполнить произвольные команды на клиенте.

Суть уязвимости заключается в возможности совершить коммит в .Git/config, что равносильно служебному пути .git/config на регистронезависимых файловых системах. Это дает возможность инициировать запуск произвольных команд на клиенте. В общем случае уязвимости подвержены рабочие станции на Windows и Mac OS X, Linux-системы будут подвержены в случае использования регистронезависимых файловых систем.

Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



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

Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.

Добрый день, читатели Хабра!

Сразу скажу, что целевая аудитория поста и события: руководители в разработке на C#/.Net, в том числе тимлидеры и менеджеры проектов. И те, кто планирует переходить на руководящую позицию.

Я поделюсь логикой формирования программы второго дня конференции Go#.
Мы взяли темы, которыми должен владеть человек на руководящей позиции в разработке. При этом конкретная имплементация этих знаний должна быть специфична для экосистемы C#/.Net.

Для мероприятия с одним треком программа получилась концентрированной. Расписание включает 10 докладов по 15-30 минут, обед в кафе и кофе брейки – и все это с 10.00 до 17.00.

Темы: от архитектуры .Net приложений до механики решений по формированию команд и распределению задач. И, конечно же, управление проектом и исходным кодом. Докладчики представят две полярные парадигмы – классическую Application Lifecycle Management на базе TFS и альтернативные подходы с применением Git и DevOps инструментов.

Наши спикеры начинали как C#/.Net разработчики, но многие имеют опыт руководства коллективами и проектами с десятками и даже сотнями разработчиков.

Сайт тимлидерского дня конференции Go# – www.gosharp.ru/TLD2014

Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:

Некоторое время назад при старте нового проекта было решено попробовать использовать Git вместо Subversion. Через некоторое время коллектив разделился на тех, кто любит Git (программисты), и тех, кто его ненавидит (дизайнеры и художники). Эксперимент по замене Subversion на Git провалился и на горизонте замаячила перспектива возвращения Subversion.

Почесав репу и содрогнувшись от связанных с Subversion воспоминаний мужики решили: «А что, мы же программисты!» и запилили свой Subversion с Git-ом и печеньками. Так родился проект git-as-svn.

Теперь мы можем использовать и Git, и Subversion с одним и тем же репозиторием. Причем доступ через Subversion напрямую использует данные Git-репозитория, в отличие, скажем, от SubGit, где для Subversion используется отдельный репозиторий.

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

Продолжаем разговор о Fossil.

В первой части мы познакомились с использованием Fossil в однопользовательском режиме на одном рабочем месте. Следующий шаг — перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в поездку. Самый простой вариант — это просто скопировать репозиторий, благо это всего один файл, на новое рабочее место. Можно так и сделать, но самое простое решение не всегда самое лучшее, есть вероятность, что возникнут небольшие проблемы.

Петр Лухин

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

Так чем же таким может быть интересна автоматическая сборка, какие возможности можно реализовать с ее помощью и каких результатов достичь? Попробуем разобраться.

Вступление

Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.

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

Приветствую вас, коллеги!

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

Какие системы контроля версий Вы используете (для собственных проектов и для работы)?

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

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

Здесь я собрал несколько рецептов, используя которые, вы сможете без единой команды git, скопировать себе репозиторий, создать там вспомогательную ветку, в ней что-то отредактировать, добавить/удалить файлы/папки, сделать пулл-реквест в оригинальный репозиторий. А по истечению какого-то времени, когда в оригинальном репозитории накопятся изменения не отраженные в нашей копии — синхронизировать эти два репозитория — причем тоже без единой git-команды.

Введение.

Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).
В предыдущем посте был описан опыт чисто системы управления версиями.
В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).

Введение.

Не так давно один из проектов, в котором я участвую, перевели из SVN на TFS. Этот проект (десятки тысяч файлов, включая двоичные файлы) много лет жил и развивался под SVN. Поработав несколько месяцев после перехода, появился некий опыт, которым хочется поделиться.
Важно понять, что это опыт человека после SVN. Я использовал TortoiseSVN (плагин для Windows Explorer) и AnkhSvn — для Студии.

мои впечатления под катом

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

В текущей версии GitHub для Windows, мы сделали небольшое изменение, которое имеет едва заметный эффект, который вы, вероятно, уже заметили. Мы изменили подход к слиянию *.csproj и похожих файлов, используемый по умолчанию.
Если вы измените .csproj файл в ветке и затем объедините ее с другой веткой, то вы возможно столкнетесь с большим количеством конфликтов слияния, нежели вы могли иметь раньше.

Почему?

Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty

Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер

Открываем страницу с SSH ключами и добавляем из буфера наш ключ

Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.

Устанавливаем и настраиваем msysgit

GitHub сегодня анонсировал запуск GitHub Developer Program, предназначенной для лучшего информирования разработчиков о происходящих изменения и коллективной работы над улучшением сервиса.



Члены GitHub Developer Program будут получать уведомления об изменениях в GitHub API, а также самый ранний доступ к новым функциям. У участников программы кроме того будет возможность запросить лицензию разработчика для GitHub Enterprise и размещать свои инструменты для рассмотрения на новой странице интеграции, также запущенной сегодня.

За несколько дней до наступления 2014 года Гитхаб успел перешагнуть отметку в 10 миллионов репозиториев. Причём больше половины из них — 5,5 миллиона — было создано в этом году. Гитхаб, несмотря на уже огромные размеры, продолжает расти экспоненциально. Если на создание первого миллиона репозиториев ушло три года и восемь с половиной месяцев, то последний миллион нарегистрировали за сорок восемь дней.

Разработка любого современного программного продукта не обходится без использования системы управления версиями программного кода (например, Subversion). Данный пост о том, что в некоторых случаях для успешного выпуска продукта одной только системы управления версиями становится недостаточно, и необходимо использовать некоторый инструмент для расширения ее функциональности.

Гладко было на бумаге

Разработчики имели разный опыт работы в нашем проекте Intel® Media SDK, и, как следствие, разное понимание рисков и последствий, которые несли их коммиты. Коммиты не тестировались разработчиками вовсе, или объем их тестирования был недостаточен.
Некоторые некорректные/не вовремя сделанные коммиты (например, ориентированные не на текущую, а на следующую версию продукта) приводили к появлению существенных (show stopper) ошибок на стадии, непосредственно предшествующей выпуску продукта. В условиях ограниченного временного ресурса разработчики испытывали немалые трудности в установлении причин их появления. Так как ошибки не могли быть исправлены немедленно, это приводило к сдвигу даты выпуска продукта.
Все это усложнялось еще и тем, что не всегда коммиты в системе управления версиями достаточно хорошо комментировались. Любые попытки изменить такое положение дел в нашем проекте были безуспешными.

Как решение вышеназванных проблем в нашем проекте был разработан CCB