Tag Archives: DevOps

6 November, 2023

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.

Scripting

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.

Backups

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.

Plugins

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

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.

Upgrades

Jenkins require you to do it from the console.

For Perforce it’s one click from the UI.

Pricing

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.

Summary

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.

21 May, 2023

Terraform

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: https://developer.hashicorp.com/terraform
You can find Terraform CLI install instructions here: https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
You might also want to install AWS CLI: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

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 https://developer.hashicorp.com/terraform/cli/commands/destroy

Here are some random notes: