#Teamcity versions upgrade
#Teamcity versions code
#Teamcity versions download

Some background: I took this project over from a colleague that left the company.

I’m thinking out loud here about the decision to go with VM-based deployment as opposed to running on ECS, which is our standard way of running workloads.

I also started to think about the migration process itself.

#Teamcity versions upgrade

I also started building a TeamCity v10.0.3 AMI for use in the new infrastructure context (the current live version not being suitable) so that we can easily test the upgrade and rollback process. Today worked on improving the code, with a fair bit of refactoring and adding some deployment wrapper scripts. Large teams probably don’t have the luxury of doing this! Day 3 Large, long-running feature branches are a bad smell and since we want to keep the old infrastructure running in parallel it makes sense to fork the code. Today I also created a new GitHub repo for the infrastructure code. I’ve also automated the database user setup by via a VPC-bound Lambda that that’s invoked by our CloudFormation wrapper script, accepting the endpoint and other pertinent details via stack exports together with secrets from parameter store and using this information to create the empty teamcity database, the “teamcity” user and password. We now have an Amazon Machine Image(AMI) with latest Amazon Linux 2 and the latest TeamCity build.

#Teamcity versions code

It was sound, but I decided to move the Elastic File System (EFS) code out into a separate template - this will promote faster testing cycles, cleaner and more comprehensive templates and, in unhappy cases, reduce blast radius. Today, I started by looking at the infrastructure code previously written by a colleague for this project.

Since TeamCity’s introduction we had moved to a multi-account AWS model and this system was designated to be relocated.

Many of the system components were not created using infrastructure code.

Not only were we missing out on new features but our version was no longer officially covered by our support contract!

We’d hadn’t taken advantage of major version upgrades and were now two off the pace.

While we were broadly happy with our TeamCity setup there were several things that needed to change: We’ve been using TeamCity as our CI system since an evaluation of various options in mid 2016. We hope this post will be of help to others performing similar migrations. This blog post follows of our DevOps engineer Ben Tisdall’s daily routine on upgrading our TeamCity CI running on AWS, back in Summer 2019. Many engineers depend on tools such as CI being highly available, making service degradation costly, especially when the company offers flexible working hours (as REACH NOW does) and/or spans time zones. Next edit the file catalina.Upgrading internal services can be as challenging as that directly used by customers. In my example my tomcat is /apps/apache-tomcat-8.0.43 cd /apps/apache-tomcat-8.0.43/bin

Now go to where your tomcat is installed and go to bin directory. So now you have java 7 in /usr/java and java 8 in /opt

So transfer that to your host and lets load it into /opt (so as root) mkdir /optĮxtract the jdk using tar command tar xvfpz jre-8u121-linux-圆4.tar If you get the RPM file that will not work well for you. so go to and select one of the middle 2 linux files depending on your machine arch.

#Teamcity versions download

Now lets download latest jdk for Java 1.8.0.121. Lrwxrwxrwx 1 root root 26 Apr 12 23:35 /usr/bin/java -> /usr/java/default/bin/java Next check to see if /usr/bin/java points to java]# ls -l /usr/bin/java Here you see that latest & default point to jdk1.7.0_101 So lets first find out what is java]# cd java]# ls -l So I am not a expert with team city but know java & tomcat and the issues of different java major versions.