Category Archives: DevOps

TeamCity vs Jenkins

We’ve been using Jenkins at Unknown Worlds for over 10 years now. It has been a solid CI/CD system allowing us to handle various tasks around our Unity Engine projects. We started using Perforce again for the new project we’re working on and Jenkins caused multiple problems with it. We had to try a different automation server. We decided to try out TeamCity. I personally love Jetbrains products, so it was quite exciting.

It turned out the systems were quite different. Let’s compare them.

Build nodes management

Jenkins is very simple – you can install the agent (jar file) manually and handle launching it by yourself. That’s it.

TeamCity is much more sophisticated. It offers an agent installer which takes care of heavy lifting. From within TeamCity UI you can clean the workspaces and restart the machine, also access the console.


Jenkins uses Groovy for scripting. It’s a very capable system you can program exactly to your needs. It offers a set of pre-defined steps, but also full logic, exceptions, file operations etc.

TeamCity has a different idea on how to handle the pipelines. It offers a list of pre-defined steps, and you manage the flow in a visual way. The scripting itself is made outside of it, but you have way better options – shell, Power Shell, python etc.


Jenkins is very traditional about it. Since it keeps all the data in flat files, you just back those up. Specifics are listed properly in the documentation.

Backup and config storage are one of the biggest selling points for TeamCity. JetBrains had a great idea – just keep all of it in git! This way we can always roll back or restore the entire TC instance. Brilliant.


Jenkins offers hundreds of plugins for almost every problem you might need to solve. They are entirely community driven, so the quality and development speed varies from plugin to plugin.

TeamCity on the other hand has a pretty narrow catalogue. I couldn’t find anything useful in it, but we didn’t really need anything outside of the standard setup.


UI is not the strong point of Jenkins. It does offer two versions of the UI – legacy and Blue Ocean. Both of them are pretty slow, outdated and chaotic. It takes a while to get used to them.

TC on the other hand offers a very modern, responsive interface. It’s almost perfect, but non-technical people require some guidance at first.

Plastic SCM support

Jenkins works great with Plastic. Occasional cleanup is required, but overall experience is great.

I haven’t tested Plastic inside of TC.

Perforce support

That’s why we switched from Jenkins to TC. Workspace management in Perforce is a terrible thing, and Jenkins doesn’t help with it at all. On the contrary – it adds another layer of misery on top of it.

TeamCity on the other hand is OK with it. Not perfect – we still have weird inconsistencies with speed, but it’s OK. Shelves and moving files is still miserable, but manageable.


Jenkins require you to do it from the console.

For Perforce it’s one click from the UI.


Jenkins is open source, so you can’t beat that.

TeamCity is pretty expensive. It’s free if you’re using 3 build agents. Anything on top of that is going to cost you. Having 10 agents is 3100 EUR including VAT for the first year, and then the price drops by 50% for the consequent years.


For me it’s a simple choice. If you can afford it – go for TeamCity. It’s the backbone for your entire company.

Got any questions? Leave them in the comments, I’d be happy to answer.

PowerShell – modifying Task Scheduler trigger

Here’s a small code snippet I wrote for modifying triggers of a specific task – I needed to add a delay for all of them.

$task = Get-ScheduledTask -TaskName "Start TeamCity"
foreach($trigger in $task.Triggers) {
	$trigger.Delay = "PT5M"
Set-ScheduledTask -InputObject $task

That’s it!


Zabbix is a very flexible infrastructure monitoring tool. Full manual is available here.

The central component of Zabbix is the server. You can find the installation instructions for Zabbix 6 on Ubuntu 22.04 LTS is available here, alternatively you can grab a pre-set up image from the download page.

The second crucial component of the Zabbix system is the Agent that provides the easiest and most flexible way for monitoring the servers. When downloading it, always use the latest version – agent2 in this case.

The configuration for Zabbix Agent is stored at /etc/zabbix/zabbix_agent2.conf

The minimal configuration for an Agent is as follows:


As you can probably guess, we configure the Zabbix server address, port, and client hostname. After the basics are configured, let’s enable the agent auto-start and make sure it picks up the config changes:

systemctl enable zabbix-agent2
systemctl restart zabbix-agent2

When that’s done, the agent is ready to be added via Zabbix GUI or auto-discovery (we’ll talk about it later).

The Hosts screen in Zabbix GUI allows you to:

  • Monitor dozens of items at the same time – server load, RAM usage, service health (reference)
  • Set up triggers for certain events (eg. /etc/paswd being modified), which can be used for notifications
  • Set up graphs for visualising your data
  • Manage discovery features (hardware – disks, partitions, network interfaces, software)

Templates in Zabbix vocabulary are pre-configured sets of features that are great for specific needs. Out of the box you can get fully-featured monitoring package for things like web servers, SSL certificates or other common use cases. Bear in mind that templates can contain conflicting item names, which could prevent you from using specific templates in some cases.

Monitoring custom scripts is relatively easy. Note that scripts are executed by the same user that handles Zabbix agent – usually that user is simply zabbix. After you create the script you want to monitor, edit the Agent config (/etc/zabbix/zabbix_agent2.conf) and define it at the bottom, following the pattern below:

UserParameter=apache_config_test, apachectl configtest
UserParameter=apache_status, systemctl status apache2.service | grep active

Remember to restart the Aagent with systemctl restart zabbix-agent2. Rest of the work is done via GUI in Hosts -> Items -> Create item. Just input the self-defined item name in the Key field, so Zabbix can pick it up.

No monitoring is serving it’s purpose without proper alerts in place. This is where Triggers come in. They usually come bundled with Templates, which makes them globally accessible. You can configure your own triggers easily, all the expected features are in place.

Notifications require some setup to work effectively. First step would be configuring the notification media. You can do that at Administration -> Media Types, where you can configure pre-defined media like Slack, Jira, Discord, SMS and many others. You can also define your own media types.

Second step is to visit Administration -> Users and configure user’s mediums – you need to set the email address, phone number and such.

Last step is customizing the trigger parameters at Configuration -> Actions -> Trigger.

Agent-less monitoring is exactly what the name says. You can monitor servers without agent installed. This limits the usefullnes of this feature, since we are limited mostly to monitoring services on open ports. We can use agent-less monitoring to check ping, SSL certificates, HTTP, TCP availability, HTTP APIs etc.

Automating host discovery is something very useful in production environment, especially where you auto-scale your infrastructure. Check it out at Configuration -> Actions -> Autoregistration actions. An example would be to accept all hosts with “Host meta data” value to set something specific (Like “webserver”), where you define two Operations:

  • Add host – to simply link it to Zabbix
  • Link to template – to attach specific monitoring package to given machine

Make sure you install and configure the Agent when you provision the new machine. The minimal per-server changes to zabbix_agent2.conf would be:

ServerActive= # Server IP

As always, make sure to restart the Agent after making any config changes.

Discovering network services is something not very useful in my use cases. It can be used to scan network IP ranges for available services, like FTP, SSH, HTTP etc.


Terraform is a web infrastructure orchestrator. We started using it at Unknown Worlds recently, and it seems like The Way of handling deployment of complex infrastructure.

Here are the basic components of the dev cycle:

  • Infrastructure specification using HashiCorp Configuration Language
  • API calls to the provider (AWS, GCP, Azure etc)
  • Provisioning – managing the software and environment on provided infrastructure
  • Saving the state of the infrastructure. This is what makes the “cycle” possible – you can iterate on your scripts, and Terraform will remember the previous state of the infrastructure in a state file

Documentation URL:
You can find Terraform CLI install instructions here:
You might also want to install AWS CLI:

Here’s an example of an AWS-hosted infrastructure that could host a website, WordPress or something like it:

Terraform’s the tool to make it work quickly! Each element can be described in a great detail, the dependencies and relations are possible to describe in a clean way, and Terraform should be able to validate it all.

Basic commands:

  • terraform init is used to initialize Terraform and download all dependencies
  • terraform plan is used to verify the access credentials and validate steps
  • terraform apply is used to apply the changes to target environment
  • terraform fmt . is used to format code
  • terraform destroy can be used to easily delete non-production environments. Production environments should be protected about this! See

Here are some random notes:

Linux Shell Scripting Cookbook

My book Pile of Shame became my tormentor. Recently I’m catching up with it just to get some closure. Most recent book I’ve read was waiting for over 10 years. Shame! I always had something better to read…

Linux Shell Scripting Cookbook by Sarath Lakshman is exactly what the title says. The book presents quite a few useful recipes to common problems. On top of that we’ll find some bash scripting basics and introduction to other common concepts.

I didn’t find much new stuff in it, but that was to be expected. Sadly, the way the book was written is pretty frustrating. One third of it are useless, repetitive descriptions and introductions. When you get over it, it might be a pretty decent read.

Here are some highlights of commands I’m not using often enough, for my own reference:

  • xargs
  • diff/patch
  • tree
  • grep (xD)
  • got to start using curl instead of wget
  • netstat
  • time
  • watch

Ansible in an hour

I stumbled upon a nice server automation course made by an expert I follow. I don’t do many tedious, repeatable tasks in my daily work, but I wanted to prepare for future.

Ansible is useful for bulk server configuration, application deployment, and other automation tasks. The course I finished is very compact, but it explains the most important topics:

  • Prepping Ansible for use (installation, management node, inventories)
  • Ad-hoc modules (running commands on all servers)
  • YAML configs (playbooks)
  • Facts, variables
  • Playbook creation (generating SSH keys, using variables, loops, groups, creating users, conditionals, file operations, tags, templates, firewall config)
  • External roles (using playbooks from Ansible Galaxy, Docker containers)
  • Creating own roles (complete web server setup example)
  • Ansible Lint (config validation)
  • Ansible Dynamic Inventory (useful for large server farms)
  • Ansible Vault (credentials storage)
  • Ansible AWX (free counterpart of Ansible Tower; a web interface for playbook management)

Looks like a quite useful, pretty complex tool. Sadly, most of the Linux servers I use are handled by Laravel ecosystem tools, so I might need to wait a while before putting Ansible to use.