This has long been one of the pain-points of a Tridion implementation. You can do it, but it's hard work and requires discipline. In recent years, we've seen the emergence of MVC-based approaches which move the templating to the web application. So with DD4T and DXA, the templating is (mostly) standard, and the customisations for your project are checked into GIT (or similar) and can be part of your continuous integration/delivery/deployment systems. This approach has become seen as good practice for a new project, but obviously, many of us also have systems to maintain that weren't built this way.
So if you are still dealing with moving templating changes up the DTAP street (and even with DD4T/DXA, your schema changes need to get deployed), you have some possibilities. The good news is that Content Porter these days makes use of a standard API on the content manager, which you can also use as part of your release process. You can see some example code here.
Keeping track of which things you want to port is also an issue. Sooner or later the discussion usually ends up with the idea of putting your release items in a bundle. Similarly, it might make sense to build a GUI extension for this. I think a few people have done this over the years, but the one that springs to mind is Albert Romkes' venerable Release Manager. Maybe others can point to similar efforts that are available in the community. If you create tooling that needs extra information/metadata about the Tridion items you are managing, you could also consider using ApplicationData.
In the end, your own problem is unique, and you'll end up composing a solution that suits you. The good news is that Tridion's APIs are open enough to allow most things you might want, but do consider moving to an MVC approach when this is possible, as that will also help with related issues like testability.