CODEWITHSUNDEEP
testingmsbuildcontinuous-integrationteamcitydevelopment-environment
Lev
Lev

Reputation: 3924

Continious Integration best practice for large project

My team has a Continuous Integration server(currently TeamCity but it doesn't matter) and large Visual Studio project which takes about 1 hour to complete full CI process after check in (build, run unit test, deploy on test server...).

Solution is splitted into 2 parts, Backend which is fully .NET stack projects (Windows Services, Web Projects etc.) and Frontend Single Page Application containing large amount of JavaScript and frontend things.

Continuous Integration build process taking 1 hour is about 90% of backend code, building, unit testing...

This is common scenario for large projects, and I want you to share your best practices and advice, on how to make "smart" check in trigger logic in a way, that each part of solution (Frontend, Backend) doesn't start build process for another.

Upvotes: 2

Views: 816

Answers (3)

Geniuslead
Geniuslead

Reputation: 99

  • Create multiple test projects example : Test.Unit.dll, Test.Integration.dll, Test.Acceptance.dll.
  • Create msbuild targets example : RunOnlyUnitTest, RunOnlyIntegrationTest, RunOnlyAcceptanceTest, this way you can control which target gets run on teamcity
  • On the team city create a build step which would run only those test which are faster example : call RunOnlyUnitTest target created earlier. Create another build step which runs longer example acceptance UI test call RunOnlyIntegrationTest target, but this step we can run over nightly or every one hour based on requirement.
  • Another option is to run a basic acceptance test locally before you commit this would save lots of time during the development cycle.

Upvotes: 0

alekseevi15
alekseevi15

Reputation: 1782

Despite the fact that Backend part and Frontend part are from the different worlds(.NET and SPA on Javascript) they could still have dependencies on each other. For example, your Frontend part(Javascript) could has link on Backend controller, which could be broken if you change routing rules. It's just shallow example, but in complex systems with a lot of dependencies between subsystems, more reliable way is to have single build. In this case you do not need to think about potential problems you may have.

BUT, surely you need somehow to optimize your single build process, because 1 hour it is a really long time.

First of all, Unit-tests(if they are really Unit-tests) should not have heavy dependencies, and should run pretty quickly, even if you have thousands of them. If test has external dependencies like database, it is Integration-test. You could separate lightweight Unit tests and heavy Integration tests between different test projects, or somehow to mark your tests to allow TeamCity to distinguish between them. For example, you could use "Category" attribute in NUnit to mark test as "Unit" or "Integration" and configure TeamCity to run ONLY Unit-tests on each build. And run Integration tests manually + periodically with regular intervals(say, each night and lunch-time).

Then, you could configure TeamCity do not deploy on dev/test environment on EACH commit, but to deploy it manually, when it is really needed. It is normal practice.

Upvotes: 1

ekostadinov
ekostadinov

Reputation: 6940

In your case this

common scenario for large projects

can be handled better on the next step - Continuous delivery. Since all the actions you describe are a natural to it. About the part with

Continuous Integration build process taking 1 hour is about 90% of backend code, building, unit testing.

this article offers very good solution - parallel testing. Of course with the agreement that it depends from your Environments. The basic idea is that processor parallelism-like execution/degree will be very efficient if done properly. After analyzing all your goals and resources. If this automation is done right - the test effort will be significantly decreased.

With the part of

make "smart" check in trigger logic in a way, that each part of solution (Frontend, Backend) doesn't start build process for another

and with the assumption in mind that

Continuous Integration server(but it doesn't matter)

a very good solution (of orchestrating Delivery pipelines with Jenkins) is described in details here. Maybe most valuable for you will be:

and

Upvotes: 1

Related Questions