1

Topic: GIT, branches and continuous integration

Day kind, colleagues. Advise where to esteem about the settled successful practice of branching of a repository in the conditions of usage continuous integration? There is at us now one branch, master, and all changes go directly there, after the code-revju. Developers locally create branches for those features over which they work, and then send on the code-revju and when the code transits , the system itself already merges all it in the master. But. For this purpose that changes were , they should transit "verification" - continuous integration collects  and launches on that  complete set of tests. Occupies all it about 5 hours. I.e. here transited my code , I received all signatures, but merge all it with the master I physically I can not, while the bild-system does not confirm that  transited all integration tests. It in this type more or less works, of course, but strongly this process irritates me and tires. Any change demands 5 hours before other developers can receive it to themselves. Yes, about that that they can take change and merge it manually with the code - I know, but it not that. It as the temporary fix approaches, when it is necessary quickly with something , but not as the general approach to operation. And if I suddenly have two-three having something in common changes for the same part of the code I can push through them in the master not earlier than through 10. 15 hours. And it at the best -  the system often produces failures for the reasons  tests, but it already another story. But here it here all does not promote that that developers sent the changes by small portions. On the contrary - they send the code-revju on 30 files then to push through it for one stopping, instead of to wait while two-three changes transit verification. Output obvious, apparently, - to select a branch for development where it will be possible to send changes with a minimum of checks ( and ), and then night  carries out all tests and sends messages if something fell off. But in this scenario we receive that design teams will work with potentially broken components - commands for us a little, it is a lot of developers and sometimes there are clashing changes of functionality that leads to the long hours lost on debugging of bugs which were brought by other command. How to be? What approaches well recommended themselves?

2

Re: GIT, branches and continuous integration

Hello, Artem Korneev, you wrote: AK> How to be? What approaches well recommended themselves? , it is enough of that when the command takes changes not from big CI, covered with all 5-sentries tests, and from developer it should run simply own tests, instead of tests of all system. I.e. if the command works over a subsystem And, and Would take changes in a subsystem what it sense to check, did not break these changes a subsystem In or ? Them after all only And interests. And so yes, it is necessary to pay for ferro-concrete reliability in absence of flexibility. Here select, according to criticality of rare breakages. If it would be desirable flexibility and speed of an exchange of changes inevitably it is necessary  a warranty  all code as a whole, and to drive manually only those tests which for the given changes seem at present important to the given command, and then to wait for results night  and the full tests.

3

Re: GIT, branches and continuous integration

Hello, Artem Korneev, you wrote: AK> How to be? What approaches well recommended themselves? I would begin with reduction of runtime of tests. Your system did not see, but, as a rule, acceptance tests one-continuous, are nonoptimally written and do not use valuably  and a disk. Fast tests over fast application considerably reduce a sharpness of this problem. Then, it is possible to use git bisect for detection specific  (at you one PR one ?) which broke tests. It is for this purpose even not necessary separate  - problem  it is rolled away directly on the master.

4

Re: GIT, branches and continuous integration

Saw such system well working. In one company known the Internet from the CIS, which type as Google. It is made, works, some thousand persons sit on it probably. Surprisingly, but any grandiose problems did not note. But there, probably, nevertheless preferentially, commands write independent slices. To estimate in your case why such approach not so arranges far off difficult. With mine  I can  about your system and suggest to think over: * there is an approach described "" TestPyramid, and, apparently, that if you live on a mode it is necessary to live on it to the end (instead of so, what to a fashionable central repository without a feature-branchej passed, and a unit tests did not learn to write, to do a software with small connectivity too, on sharing on components and do not want to reflect) ** what proportions at you between different types of tests and what amount? ** what about times of running, assembly? ** what technology of programming? * at you  a software that can be a sign of badly designed software and consequently you test all long tests of the uppermost level (they already more likely even not simply functional, and acceptance, integration end-2-end) which should be not much in comparison with other tests, whether also which in well tested system can be launched on "night" assembly as wrote colleagues above ** it is possible to isolate testing of components and integration testing in between * at you bluntly feeble infrastructure ** look at loading of machines if it more than 80 % from any peak value on the average - go to a manual and show that 5  waitings by the developer stand more than the server (it is difficult, long, but it is possible  improving) * from niche can tell that can take place the bad test design and feeble system of automation ** on the first - is necessary to look at coverings and to get rid of unnecessary checks; what generally testing strategy? ** on the second - the code  all tests developers do ( can not cope up to the end with good design of the code of autotests and )? ** always there is such term as smoke tests (badly, but it it is possible) and to drive only them As to  depending on speed of the assembly, present resources, it is possible to collect everyone   the developer, to put somewhere in , to launch long tests at the nights if there is a regress for a night for  it is already possible to use assembled artifacts, instead of to waste time on the assembly. Well and actually about to esteem, the link to the test a pyramid above to begin with. In dialogue can we open nevertheless in what a problem. For now to me through a prism of my templates to me sees (that that described above) that at you most likely  and  badly designed system for which developers do not want to write tests (and can even it is necessary to think of application ) which on top is still polished with a feeble infrastructure. And generally, we remember golden rules, on which majority of my colleagues of developers (meaning that I ) put a bolt: * the code of tests is the code of the program (instead of something is unnecessary auxiliary) *  (, ease ) a software is one of program features (as any another business a feature, as the documentation,  and maintenance) as product

5

Re: GIT, branches and continuous integration

Hello, Artem Korneev, you wrote: AK> But. For this purpose that changes were , they should transit "verification" - continuous integration collects  and launches on that  complete set of tests. Occupies all it about 5 hours. 5 hours to wait to make  is a violence over collective the full tests 12 hours can and to run, it is quite spread, but it should not hinder to work ( the code) I could advise to divide tests on slow and fast. The fast it is direct on  it is possible to launch, and slow or on demand, or time at midnight (or hardly earlier that results by the morning were) at  midnight tests on ci normally is the list entered . Whether the author of everyone  can check up it broke  ( besides from ci to everyone can come)

6

Re: GIT, branches and continuous integration

Hello, Artem Korneev, you wrote: AK> But in this scenario we receive that design teams will work with potentially broken components - commands for us a little, it is a lot of developers and sometimes there are clashing changes of functionality that leads to the long hours lost on debugging of bugs which were brought by other command. Here it is possible to advise to divide nevertheless responsibility of commands. Two persons should not saw the same classes, nevertheless more largely tasks it is necessary to produce everyone saws the cube, and on a joint already potentially there can be problems. It is all dares if in advance to think over, especially, "a seam type" between components though many and consider that the code should be the general and without the master, nevertheless the brothel should be avoided

7

Re: GIT, branches and continuous integration

Hello, jazzer, you wrote: J> Imho, is enough of that when the command takes changes not from big CI, covered with all 5-sentries tests, and from developer it should run simply own tests, instead of tests of all system. Well i.e. somehow to fix test sets to parts of a tree of source codes and in a developer branch to launch only the tests covering immediately this subsystem. And it is possible to test all at night. Yes, I about this variant already too thought. I will offer for arguing in a command, as one of approaches. J> if it would be desirable flexibility and speed of an exchange of changes inevitably it is necessary  a warranty  all code as a whole, and to drive manually only those tests which for the given changes seem at present important to the given command, and then to wait for results night  and the full tests. Here with night tests to me it is not so clear. Well it, let us assume, fell at night. How to understand, whose  broke all? The same for normal day easily can be pair of tens , and is closer to release and from fifty.

8

Re: GIT, branches and continuous integration

Hello, scf, you wrote: scf> I would begin with reduction of runtime of tests. Your system did not see, but, as a rule, acceptance tests one-continuous, are nonoptimally written and do not use valuably  and a disk. Fast tests over fast application considerably reduce a sharpness of this problem. Not, there to climb it is useless. Those tests are written not by us, and testers. Other command, other management. Tests for a python, on basis  platforms. I there looked few times, there even to understand difficult, not that that something to correct. Plus all delights of a python as interpretive language - often all breaks in one and a half-two-three hour after start because of a simple misprint. scf> then, it is possible to use git bisect for detection specific  (at you one PR one ?) Which broke tests. One running of tests occupies 5 hours. To launch tests two times for a night - it is difficult, three times - it is physically impossible. So  does not approach. Worse that is it now there 5 hours, and will be it is even more. There while even there are no tests for "our" functionality, there tests for already existing features, instead of for this purpose over what we now work. I.e. kol-in tests will increase, complexity of possible configurations will raise and in half a year we easily receive 7. 9 hours on running of all tests. It is theoretically possible  testers, to define, which test fell and to launch in  only this test. But there minutes 40 leaves on development test , and the test occupies from several seconds about several minutes. In this variant there is any chance to have time to find  iteration though already and there will be no warranty that all remaining tests with this iteration work. scf> it is For this purpose even not necessary separate  - problem  it is rolled away directly on the master. I with  did not work while. But not so I understand - and how to roll away one ? Subsequent  after all can and break.

9

Re: GIT, branches and continuous integration

Hello, zubactik, you wrote: Z> ** what proportions at you between different types of tests and what amount? Z> ** what about times of running, assembly? Z> ** what technology of programming? Not, well at me a question not under tests, and on the organization of operation with a repository. Tests I mentioned to explain that our current approach with the full running of all tests for everyone  is not so successful and demands improvings. I want to listen, as people quit this position. There objectively difficult big system, tens interacting components in different languages, own engines no-sql databases, own modifications of RPC-reports with generation  for different programming languages, the components working as the driver for Windows and Linux, the components working in clouds. ... In a test surrounding, accordingly, are launched services,  imitating operation API of cloudy services (Azure, AWS) that actions were fulfilled not in a real cloud, and in our stubs. Now looked in the repository search, it told that at me in a folder of source codes of 20 thousand java-files, about 10 thousand files on With, 40 thousand files on the Python, some thousand on With ++. And it not a unique repository - integration tests lie separately, in  the repositories, any else components have the separate repositories. Our command on 30. 40 persons saw only that part of system which is integrated with clouds. And so it is o-very big project developed by set of design teams. We cover the code with tests, certainly, but need for integration tests all the same remains. As system parts actively enough use each other and are integrated with each other, we receive set of possible scenarios of usage and complete set of tests will long go for quite objective reasons. If I change something in structure of the saved data, saved a web service tests should  check up that that structure will normally be deserialised by the driver under Linux. I think to cease to launch all integration tests after everyone , to shift it on the night assembly, but not so I understand how then to understand with breakages. The probability of is very great that we will have every day though one fallen test and a master branch  generally will never receive changes. After all next day it will be necessary anew  corrected , broken tests, plus a part  which went after it, plus new  - we receive a snow clod. Whether Z> ** it is possible to isolate testing of components and integration testing in between it is not isolated Yet. I here suspect this subject. About other components I can not tell, but for components of our command I saw only units-tests which we write, and integration tests which are written by a command of testers. Tests which would check separately serviceability of our component, I did not see. Z> ** on the second - the code  all tests developers do ( can not cope up to the end with good design of the code of autotests and )? Not, there other command, they do not submit to us. Z> as to  depending on speed of the assembly, present resources, it is possible to collect everyone   the developer to put somewhere in , to launch long tests at the nights if there is a regress for a night for  it is already possible to use assembled artifacts, instead of to waste time on the assembly. Here it is the interesting moment. It is necessary to consider with  and testers.

10

Re: GIT, branches and continuous integration

Hello, Artem Korneev, you wrote: AK> I with  did not work while. But not so I understand - and how to roll away one ? Subsequent  after all can and break. Can, and often break, it is the creative task - or to roll away only one (doing some fighting with conflicts), or it is stupid to roll away everything that hinder to roll away the bad.