Category Archives: Automation

Introduction

With Vagrant we can build and share reproducible and predictable environments using environment-as-code principles.
Vagrant can deploy both on-premise environments based on VirtualBox, VMware, Hyper-V, Parallels and cloud, such as DigitalOcean, Azure and AWS.
I prefer to use tools like CloudFormation to build cloud environments, so I’ll focus on on-premise in this post.

Vagrant can also work with Docker, but now we have native Docker not only on Linux, but also on Windows and OS X, so Vagrant can be used only for complex or legacy Docker scenarios.

It’s quite common practice to keep databases on dedicated servers nowdays, especially if you use AWS RDS or Azure.

Relational databases performance is always painful and you might want to split data across at least a few databases. But if data is divided you still to have to do some logical operations across the whole amount and it’s quite simple, so let me show how it can be done using bot SQL Server Management Studio and CLI.

When you do some CI/CD jobs you might want to mark some builds with name of the current (active) Jira sprint.

We have a dozen components in the project with dedicated Jira projects and sprint names are like “Backend sprint 12”, so you probably don’t want to add useless information to the build and need only number to identify build.

Jira has a nice REST, so you can get what you want in a very simple way:

Although XCode server is almost perfect for building iOS apps, Jenkins is still more popular. If your application consists of a few parts such as a database, backend, frontend, Android, and iOS apps you typically want to have the same CI/CD for all components.

My Jenkins master is running in AWS cloud together with a dozen of Linux and Windows slaves. However, iOS app can be built only on macOS and you have to use Apple computer to build it. It’s typically a Mac Mini computer located in the office.

In this post we’ll consider secure and reliable connection between mac in the office and Jenkins master in AWS cloud.

Both Jenkins and GitHub are very popular, so it couldn’t be a problem integrating them. It still might be a bit confusing if you’re doing it for the first time. That’s why I decided to spend a few minutes to show you guys how it can be done.

Jenkins master can be accessed through the URL different from the one specified in Jenkins configuration.

Why might we need this? Well, you probably want your Jenkins server to be publicly accessible (this is required for GitHub integration, by the way) and since it’s public you typically want to use an encrypted HTTPS connection.

Well, you can install nginx proxy to achieve this, but in this case you’ll have to maintain SSL certs, which obviously sucks, especially if you can use AWS Certificate Manager with AWS ELB.

Another reason to use different URL is to save your time. When you use Windows slaves via JNLP there’re well-known issues with both nginx and load balancers.

And the last but not least reason is that “LAN” connection between Jenkins master and slaves is still more secure and faster, so it’s preferable in most cases.

So let’s start implementing Jenkins and GitHub integration within these conditions!

In one of the previous posts I explained how to create a custom box running Windows.
So in this post I’ll show how you can create your custom box running Linux – both CentOS and Ubuntu.
I won’t use Packer in this example – just regular VirtualBox and shell commands.