- Installing and configuring TeamCity 2017
- Working with projects and build configurations
- Ensuring code quality with testing and inspections
- Monitoring branches and pull requests
- Transforming Web.config files for ASP.NET projects
- Deploying your build artifact with AWS CodeDeploy
- Managing and triggering builds
- TeamCity 2017 administration
Skill Level Intermediate
- [Instructor] Hello, and welcome to the course, Continuous Integration and Delivery with TeamCity 2017. The reason that I am concise on 2017 is that in this version, TeamCity has gone through so many changes, and it's coming with new features that if you learn TeamCity based on anything that explains it upon version 10 and before, you're not gonna be able to use TeamCity efficiently if you get the latest version from JetBrains' website.
The date that I actually started recording this course is 1st of January, 2018. And as new features and changes come from JetBrains, I will basically send you updates via the announcements in the course and I will keep you updated. So what is TeamCity? TeamCity is a powerful and user-friendly continuous integration and delivery tool which supports many programming languages, environments, and server types.
TeamCity is common amongst .NET developers, but basically any language that you use is okay. You can build and deploy your programs written in PHP, Python, Node.js, Java, and of course, .NET. And again, you can install TeamCity on your server type of choice. For example, you can install it on Windows, you can install it on Ubuntu, and any UNIX-based server.
We said that TeamCity is a continuous integration tool, but what is continuous integration? Continuous integration is a software development practice to make sure that changes that are made by different developers will integrate together well. Why we say the code should integrate well together, I will explain it on this slide. You normally have a source control system such as your hosted gate, or gate hub, or bit bucket.
If you work on your personal projects and you don't have a source control system, I do advise you to use a source control system because it's for obvious reasons. You don't know, the next day, your machine may break, and you may lose your source code. Your source code is maintained in a source control system. What developers do is that they check out or clone the source code onto their local machine and basically work on new features, or fix the bugs, and change the code.
Obviously, as a developer, before you push the code back into source control system, you build it on your machine, you run it on your machine, and you make sure that it works perfectly. If you have automated tests, which I hope you have, you run them and you make sure that all the tests are passed and they're all good. But the problem is that other developers make changes as well, and when you put all these changes together, chances are that the code may break and application might not work, or the tests might not pass.
So what we do is that, in here, you commit your change to source control. The TeamCity build server is watching the source control system, and as soon as it detects a change, it builds the code that is gonna be committed back to the source control system. You can build the code and see if it builds without any problems. If it does, then you run the unit tests if you have any, and you make sure that all your unit tests are passed.
Then you can also run code quality checks and code coverage, like duplication checks and all those kinds of quality checks on the source code. And depending on the level of standard and quality you want enforced ... The basic level is that the code should build, and you can go all the way through to running the unit test and running the code quality checks. You can avoid the commit from happening, so you won't allow a broken code to go to your source code.
So that is continuous integration. If you deploy what you build, which is called a build artifact, automatically as well, you have a continuous integration and continuous deployment. Let's have a look at some features of TeamCity before we go ahead and work on the best architectures you can have for your continuous integration and delivery system. TeamCity can build multiple projects concurrently on different platforms.
Each project may include code of different programming languages, and the build may be done in a different operating system. You can have one TeamCity setup, but your teams may use different technologies. For example, my current company has a .NET team and they have a PHP team, but we don't have two separate TeamCity's. We have one TeamCity. The TeamCity can run the code changes that are made by two teams, and they can execute the builds concurrently and then deploy them to different environments.
Obviously the way you build and compile your code in PHP and .NET are different, but for TeamCity, it's not a problem. Also you can optimize the code integration cycle and make sure you never commit broken code back into the code repository. I just explained this because TeamCity can watch your code repository, and if it detects a code change, it compiles your code and makes sure that the entire thing will basically build when all the code changes all come together.
After that, you can run unit tests and see the test results on the fly. So if you have automated unit tests, TeamCity can run the tests, make sure that all the tests pass. Within TeamCity, you can see the test results. You can also, on top of running tests, you can run code coverage and code analysis, too. But this feature is only supported if you have .NET projects and/or Java projects. TeamCity is also very highly scalable and highly available.
Just in the next lecture, I will show you how you can set up your TeamCity in a way that it's highly available and it's highly scalable. The more your team grows and the more projects and build configurations you put into your TeamCity, it can scale up without any problems. Potentially, it's low-cost. An important factor of having a system in place is the cost of ownership, and TeamCity relatively has a low cost of ownership.
The reason is that, I will show you in the upcoming lectures, the reason is that TeamCity is able to spin up new machines in order to run the builds, and then once you don't need or you don't use them for a while, it gets (mumbles). So if you set up your TeamCity and continuous integration system on the cloud and you don't really need the build agents at the moment, it can stop them, so you won't pay for the machines and build agents.
And then when you need them again, it can spin them back on. It's gonna keep your cost at minimum size. And also, TeamCity is very easy to use for developers, and the learning curve is quite short because your developers will have to use TeamCity to adjust the configurations. If they don't create them from scratch, they can do that as well. So the learning curve is very short because TeamCity is very easy to use.