Рано или поздно разработчик всерьез задумывается о фрилансе. В этот момент большинство идут на биржи. Выбор бирж огромен. В СНГ: fl.ru, weblancer и прочие. Но когда доходишь до дела начинаешь понимать в каком все упадке. Единственным местом где водятся более-менее нормальные заказы можно назвать fl.ru и еще одну-две биржы. Но на fl.ru нужен pro аккаунт, ведь оказывается чтобы взять заказ нужно заплатить бирже, и далеко не факт что тебе что-то светит. Поэтому было решено идти на Upwork.

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

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

Сертификация Microsoft предназначена для специалистов в различных областях, связанных с информационными технологиями, а также c сертификациями аппаратного и программного обеспечения на предмет совместимости с продуктами Microsoft.

Экзамены сдаются в центрах VUE. Экзамены по направлению Office сдаются в Certiport центрах тестирования.

Стоимость экзаменов обычно равна 80$ (60 EU), но некоторые экзамены могут стоить дешевле (60$).
Общую картинку можно увидеть на следующем плакате:

Дисциплина тестирования на просторах нашей родины всё ещё продолжает бурно развиваться. Это утверждение может показаться вам спорным. Но я вижу всё больше людей, которые хотят подойти к тестированию более структурировано, осознанно, “научно”. Этих людей интересуют не только вопрос “как”, а ещё и вопросы “почему” и “зачем”. Такие люди встречаются мне всё чаще на работе, на встречах тестировщиков, на занятиях для начинающих, которые я веду.

Люди задают мне и друг другу вопрос: что читать тестировщику? Как подтянуть свои знания до уровня своего опыта? Мой ответ — читать надо как можно больше. Но, как и в любой деятельности, рациональность не повредит. Можно ли прочитать немного меньше, но получить пользы больше? Мой ответ — это можно сделать с помощью сертификации ISTQB. Подготовка к экзамену даст хороший обзор знаний, которые могут пригодиться тестировщику. Сдав экзамен, вы получите документальное подтверждение знаний.

Давайте посмотрим, каким образом ISTQB-сертификация может быть полезна вам как тестировщику.

Дрейк и не знал, насколько был близок к подбору правильного тестировщика.

Рано или поздно может настать момент, когда к вам придут с просьбой найти тестировщика. Можно, конечно, почитать какую-нибудь литературу про тестирование – например, «Тестирование Дот Ком» Романа Савина. Да только, вполне возможно, кандидаты её тоже читали.

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

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

Не так давно свет увидел World Quality Report 2017–2018 (Мировой стандарт проверки качества), выпущенный благодаря совместному труду сразу нескольких крупных компаний (Capgemini, Sogeti и Micro Focus), в котором было отмечено ряд интересных трендов в разработке и тестировании программного обеспечения. Авторы этого отчета считают, что основные направления в развитии разработки ПО заключаются в постоянном совершенствовании автоматизации тестирования и повсеместном применении гибких и DevOps-методологий (методология, которая объединяет в себе работу программистов и системных администраторов). Так, в данном отчете указано, что компаниям необходимо внедрять интеллектуальную автоматизацию и смарт-аналитику, для того чтобы ускорить процессы принятия ключевых решений и валидации продукта. Благодаря таким нововведениям компании смогут более эффективно справляться с тестированием интеллектуальных устройств нового поколения и высокоинтегрированных продуктов, изменения в которые вносятся постоянно. В отчете также говорится о необходимости создания интеллектуальных платформ для тестирования, характеризующихся высоким уровнем адаптивности. Благодаря таким платформам можно будет обеспечить эффективную поддержку полного жизненного цикла приложения.

Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий — степень изолированности кода). Тестирование бывает:

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

Классификация хорошая и понятная. Однако на практике выясняется, что у каждого вида тестирования есть свои особенности. И если их не учитывать, тестирование станивится обременительным и им не занимаются в должной мере. Здесь я собрал подходы к реальному применению различных видов тестирования. А поскольку я пишу на .NET, ссылки будут на соответствующие библиотеки.

В начале 2019 года мы (совместно с порталами Software-testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.

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

Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

Разработчики CI\CD-инструментов часто указывают в качестве клиентов крупные компании — Microsoft, Oculus, Red Hat, даже Ferrari и NASA. Казалось бы, что такие бренды работают только с дорогими системами, которые не сможет позволить себе условный стартап из пары разработчиков и дизайнера. Но значительная часть инструментов доступна и для небольших команд.

На что можно обратить внимание — расскажем далее.

В мае 2019 года GitHub анонсировала выход сервиса Package Registry. Вслед за этим, уже в августе, была анонсирована поддержка CI/CD в Actions.

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

На прошедшей «GitHub Universe» компания анонсировала много разного, но меня больше всего «зацепило» их собственное CI/CD решение. Основано на Docker, может собирать и выполнять контейнеры по пушу в репозиторий, появлению нового тикета, созданию релиза. здесь можно оставить заявку на участие в публик бете, Microsoft будет выдавать инвайты небольшими пачками. Под катом — мои спекуляции чем такая штука может быть нам полезна при живых GitLab и CircleCI.

Добрый день.

На Хабре уже есть несколько статей о jenkins, ci/cd и kubernetes, но в данной я хочу сконцентрироваться не на разборе возможностей этих технологий, а на максимально простой их конфигурации для постройки ci/cd pipeline.

Я подразумеваю, что читатель имеет базовое понимание docker, и не буду останавливаться на темах установки и конфигурирования kubernetes. Все примеры будут показаны на minikube, но так же могут быть применены на EKS, GKE, либо подобных без значительных изменений.

Я хочу поделиться с вами историей, как мы строили CI/CD-процессы для ПО, написанного для нестандартной платформы, которую многие считают «динозавром» — IBM System i aka AS/400.


AS/400 используется многими крупными российскими банками, и все они потихоньку движутся в направлении CI/CD. Райффайзенбанк стал одними из первых (если не первым), кто применил эти практики для установки ПО на платформе AS/400 в промышленной эксплуатации.

Обычно в термин «поддержка» вкладывают только один смысл — это реагирование на беды с хостингом, замена битых дисков, настройка веб-серверов и СУБД, общее повседневное администрирование. Но, на самом деле, это только первый уровень контроля стабильности работы любого интернет-проекта.

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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

7 ноября на конференции HighLoad++ 2017, в секции «DevOps и эксплуатация» прозвучал доклад «Лучшие практики CI/CD с Kubernetes и GitLab». В нём мы делимся практическим опытом решения проблем, возникающих при построении эффективного процесса CI/CD на базе указанных Open Source-решений.

По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.