Is it a good practice to capture build artifacts in Artifactory that Jenkins produces

There are a number of scenarios where your deployment could be different per environment:

1. Which machines are being deployed to (obviously).
2. Config files (you mentioned this).
3. Number of machines (or VMs) per environment.
4. Load balancer.
5. Network configurations.
6. Authentication.

There could be lots of others, but it's hard to say without more info on your specific project.

As for storing binaries, it is fairly common to store build artifacts somewhere, but I'd recommend using an actual artifact repository rather than a "source code repository" like SVN. You'd have build jobs that create the artifacts (release or in-progress) and put into the repository. Then you'd have other jobs that deploy the artifacts to servers. You can combine them, but that gets to be a lot on one job and you start losing granularity.

(Aside: I've got some experience using Maven, Nexus, and Jenkins for C# webservices... but that's some real craziness for most .NET developers. But once you've got Maven working for you in .NET-land -- instead of against you -- then you gain some neat benefits.)

I find using a snapshot approach using the maven snapshot functionality works fine out of the box.

Maven will automatically grab the latest snapshot release from the repository for a particular major/minor build number.

It then becomes only a matter of updating the major/minor version numbers when you do a release, and maven can do that for you as well through the maven::release command.

I normally use Jenkins/Hudson to build the release and upload the artefacts to the repository on completion of the build. I have used TeamCity before but find Jenkins a much more featured CI utility.