Feature #1261
openAutomatically prepare builds of development branches each night
0%
Description
I'm thinking about auto-building each "current" development branch (not just master) each night. Thus, in the morning we could have a fresh build of all the development branches, which would allow us to continuously and automatically evaluate their quality at each push. This means, we may mitigate the panic we have at the end of our sprints, when we expect tests to work, but they do not. However, we don't want to lose the pace of development, and the speed we can exchange commits...
So, my proposal is like this:
- Each "current" development branch is auto-built at night (and, perhaps, it's tested with middle tests)
- At commits to this branch, small tests are executed (as with
master) - However, commits are pushed to itgdev at once, before the tests are run for them
This way we won't lose the pace of commits exchange, and will always have results of middle and small tests for development branches. We will detect the issues earlier, and will be released from the burden of running tests manually.
What do you think?
Updated by Pavel Shved over 13 years ago
One thought is that there'll be too many simultaneous testing to avoid resolving #833 prior to this.
Updated by Evgeny Novikov over 13 years ago
I just want to add that there are too many development branches at the moment and we shouldn't forget about "cleaning day".
Updated by Alexey Khoroshilov over 13 years ago
I like the idea very much. I would not happy to have many simultaneous testing on the same machine since they can interfere by various reasons (e.g. memory limitations) that makes test results less useful.
To begin with, we can just manually configure a smaller set of development branches.
Updated by Pavel Shved over 13 years ago
The measurements demonstrate that the average utilization of the machine during testing is about 60%. With 2Gb more memory, which a forthcoming equipment purchase will add us, machine will be utilized on 100%, the insufficient memory not being an issue anymore.
We invested a lot of time into our source:shared/sh/timeout script (see also bug #974) to mitigate issues that arise when running on an overloaded machine (unless it performs a lot of memory page swaps). Simultaneous testing of, say, two branches at a time is totally OK today.
Updated by Pavel Shved over 13 years ago
Or, we can make the tests themselves run concurrently...
Updated by Alexey Khoroshilov over 13 years ago
Pavel Shved wrote:
Simultaneous testing of, say, two branches at a time is totally OK today.
Two looks like a reasonable number in this configuration. I meant I would not happy to have a lot of simultaneous testing.
Updated by Pavel Shved over 13 years ago
Alexey Khoroshilov wrote:
Two looks like a reasonable number in this configuration. I meant I would not happy to have a lot of simultaneous testing.
Well, that's a technical question (and quite easy to solve).