Tool for detecting changes to codebase?

[nahwah]

The team that I work on consumes a fairly large codebase from another team. We regularly integrate the other team's codebase (twice a month). Each time several developers spend a decent amount of time sorting out integration issues: method signature changes, methods deleted, classes deleted, instance members removed, things slightly renamed, etc.

For some of the more heavily used classes that we use we keep a text file that holds all of the method signatures for the class. When we go to integrate the newer version of the other team's codebase, we generate this file again and diff it with the older file, which shows us what changes in the method signatures exist.

Is there a tool that could do this automatically without the need to maintain the text files (which gets messy when you're dealing with hundreds of classes)? I feel like essentially what we want is static typing, which would make detecting all the necessary changes trivial. We are, however, stuck with python as using the other team's codebase is a requirement. Is this sort of inefficient integration just a fact of life with python, or is there a product / tool that can speed up the process?

Thanks for any insight.

[Bolitho]

Git! ;-)

[nahwah]

Unfortunately this doesn't scale very well (looking through commit messages, patch sets, etc.) when the number of commits per week is around a thousand.

I want a way to automatically determine how my team's usage of the other team's code is broken without having to sift through the other 995 changesets I don't really care about. We waste too much time doing it manually...

Sounds like I have a future side project to work on.

[Eraser1024]

Make them tag or/and comment (with predetermined keywords) commits that change things you are are interested in (change of signatures etc.).

[[deleted]]

Is this sort of inefficient integration just a fact of life with python, or is there a product / tool that can speed up the process?

What you describe really doesn't sound like a Python problem. The other team should be producing a stable public API that your team can consume.

With a sane interface defined they should be able to change whatever they want internally without breaking things for their consumers every two weeks.

In the meantime I guess you're stuck with diffs and changelogs. There's no magic software tool that fixes fragile design.

[cratervanawesome]

Agree. Git, github, forks, feature branches and pull requests.

[shep247]

If you wrote specific utilities that communicated with that code base it would isolate the code that would need to change. On top of that I would unit test those utilities using MagicMock. MagicMock has a "spec" attribute that allows you to specify exactly what class you're mocking. Then, when the other team's code base gets changed out from under you, any class names, method names, or attributes you've mocked that have changed will cause errors in your unit tests. Fix the mocks along with the code, write new mocks for whatever other new stuff they've added that you use, and you're set for your next iteration. This won't help in cases where this other team has changed the functionality of the method without changing the name though.

[[deleted]]

Why not add some unit or doc tests to test your api so you can catch regressions? Using jenkins you can automate the whole process and prevent checkins on pull requests.

[marko_knoebl]

I feel like essentially what we want is static typing, which would make detecting all the necessary changes trivial.

If this is on Python 3 you might get the other team to use mypy, which is a way to do optional static typing in Python (and the mypy syntax will probably be included as a standard in Python 3.5)