Your situation sounds remarkably like the state of our (also Python) codebase 18 months ago. Start with CI and a couple of trivial tests that don't require ref

Your situation sounds remarkably like the state of our (also Python) codebase 18 months ago. Start with CI and a couple of trivial tests that don't require refactoring - a smoke test or an end to end test that verifies your home page returns a 200 status code. Expand from there. I say this because tests are useless if they don't get run. When I finally got CI set up for our code base, my next three weeks were spent updating abandoned tests that had been written to verify a dependency upgrade and then hadn't been run in months. The real win, though, was integrating CI with Slack. Before that nobody noticed if a build broke, and I would have to point it out to them. Displaying an alert publicly in the middle of our primary channel of communication made it something that couldn't be ignored. Once you have CI running, developers will start to feel the pleasure of expanding test coverage and using tests instead of clicks to verify their work... and the pain of breaking the test suite. Before we set up CI, every member of our dev team was somewhere between unenthusiastic and mildly resentful of requests for test coverage. That attitude has changed - most of our engineers now take pride in writing tests that pass, and one formerly resentful developer voluntarily chose to target 100% coverage (something we don't yet require) for the most recent feature he built. Also, I want to echo another commmenter's suggestion about using a hosted CI service - assuming you're a small team. It'll get you up and running faster and require less maintenance overhead. Since we don't use Docker and have a fairly complex stack that won't run on typical services like CircleCI, we use a service that handles the queue, displays pass/fail, supports notifications, etc. but lets us run the test suite itself on our own boxes.