I don't want this CI

Published at March 13, 2019 ·  1 min read

I love CI and I’m sure that it’s a required part of the software development. It helps a lot to test software to find issues as soon, as possible. CI save thousands of person-hours by automatically project testing. It works almost in the background and guides you to the next steps: go forward or step back and fix the issue.

Everything is written above is valid only for good CI. It should not be too noisy. It tesh every change in a automatic way. It’s stupid if you need to run some tests on “CI” manually. It’s not CI. A lot of false-positive jobs makes CI annoying. If there’s a lot of non-voting jobs, it’s not useful at all. You’ll ignore such jobs in the future if they fail on a regular basis. All tests results should show you the current status of a project or a patch. If tests results are not clear, it means that CI or tests should be changed.

Right Way to Setup Jenkins in Docker

Published at February 21, 2019 ·  1 min read

I was for this solution for months. Almost any guide I’ve found was about using an official Docker image with few plugins installed. It works pretty well if you agree with a manual initial configuration like configure admin user and password. It doesn’t work at all if you deploy Jenkins in an automated way.

Here is a Dockerfile to get installed and ready to use Jenkins:

FROM jenkins/jenkins:lts

# https://github.com/jenkinsci/docker/blob/master/README.md

# Jenkins configuration
ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false"
COPY security.groovy /usr/share/jenkins/ref/init.groovy.d/security.groovy

# Jenkins plugins
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt

security.groovy content:

Deploy Hugo Sites With Jenkins

Published at February 17, 2019 ·  2 min read

I’ll describe how I do my Hugo-based blog updates with Jenkins, but it’s pretty similar to any other static site generator.

Pre-requirements

Jenkins installation is out of the scope of this post. Also, you need to have installed and configured Publish Over SSH plugin.

Also, I use Jenkins Job Builder (JJB) to configure Jenkins jobs from yaml file.

I’ll describe my blog-jobs.yaml config for my blog below.

Jenkins configuration

Views

If you have a lot of jobs or just want to group them by project, it makes sense to create a view:

Choosing CI server for local needs

Published at February 15, 2019 ·  2 min read

Implementing everything-as-a-code initiative, I need some CI server up and running on my desktop. I don’t want to use cron directly or implement something myself because of I don’t have enough time for it.

That’s mean, I can’t use Drone, Circle CI, or Travis CI because of pricing. I tried Buildbot and GoCD and they look pretty good but not mature enough.

I really like GitLab CI but it requires a lot of resources and looks like too powerful for my simple tasks. I can say the same about TeamCity. It’s one of the best CI servers I ever used.

Personal Tests Anti Rating

Published at January 20, 2019 ·  1 min read

Here is my personal test anti-rating. If I see something from this list, for me it means that the testing process on this project is not ideal.

5. You can’t run tests on your development environment

It depends on a project ad kind of tests, but you should be able to run unit tests at least on your development environment. Otherwise, you’ll waste your time and CI resources waiting for tests results

Everything as a Code

Published at January 16, 2019 ·  2 min read

Infrastructure as a code… I hear about it during at least last 5-7 years. There are a lot of activities in each company (I hope) to introduce configuration management like Ansible, Puppet, Chef, etc to achieve Continuous Integration and Continuous Deployment(Delivery) aka CI/CD.

I saw a lot of successful implementations for CI/CD for small and mid-size projects. It’s harder to introduce full automation on big projects but it’s absolutely doable.

Enterprise vs OpenSource на примере Travis CI

Published at January 16, 2014 ·  1 min read

Выбор версии языка программирования, фреймворка - сложный вопрос, который всегда бурно обсуждался и будет обсуждаться. В enterprise мире часто, но не всегда, используют старые и проверенные инструменты. В то время как Python 2.7 все еще нет из коробки в RedHat/CentOS/др дистрибутивах, в некоторых уже используется Python 3.3, пусть и не в качестве системного. В мире opensource - наоборот, часто используют только самое-самое новое. Но это правило не относится к разным фреймворкам. Представьте, что завтра, например, Django будет поддерживать только Python 3.4, который еще не зарелизился. Никто им пользоваться не будет. Вот и приходится поддерживать несколько версия языка программирования. Похожая ситуация с paramiko, nose и другими популярными проектами/инструментами/библиотеками.

Параллельные билды в Jenkins

Published at November 15, 2013 ·  2 min read

Разберем ситуацию, ставшую достаточно распространенной в наше время. Есть распределенная команда, допустим в двух городах (А и Б), которая работает над одним крупным проектом. Сборка проекта происходит на Jenkins’е в городе А и длится, например 3 минут. Скачать готовый продукт из города А в город Б можно в среднем за 30 минут (в зависимости от времени суток, загрузки канала, фазы луны и т.д.). Итого: команде из города Б нужно ждать час(60 минут) чтобы запустить/протестировать свежий билд. Очевидно, это достаточно много. Нужно ускорять.