The "real" answer depends on where you intend to get your CC evaluations performed. There has been a recent upheaval in the CC evaluations world with US and Canada (and Australia) in one camp, and most of Europe in another camp. (I see from your uid that you may be in France.) Specific schemes may have specific requirements. You will need to contract with an evaluation facility anyway, so you might as well get that ball rolling.
The reason why the location is important is that the US/CAN market is moving to assurances at EAL2 and lower (and then they are going to get rid of assurance levels altogether). At EAL2, the only two things in scope for "infrastructure" purposes are the configuration management system and secure delivery/supply chain.
The requirements for EAL2 are pretty modest and basically say that you NEED to have a CM system and the product and documentation has to be controlled within the CM system. However, no demands are made on specific functionality other than to show that it is controlled (it doesn't even need to be automated for EAL2).
Now, in France, if I've correctly translated, the CC scheme (ANSSI: Agence Nationale de la Sécurité des Systèmes d'Information) appears to be continuing down the path of medium-to-high assurance certifications (eg. EAL4 and up). At EAL4, there are significant security requirements levied on the development environment, tools, and the CM system.
The key, however, is that the CC is not prescriptive: it doesn't tell you what security functions you must have, only what the end result is (eg. it must protect the confidentiality and integrity of the product). One of the key things to remember is that where the developer's measures are deemed less than adequate by the evaluator, a clear justification must be provided based on the potential for an exploitable vulnerability.
I suggest you first look at what level of assurance you are looking to achieve (usually a marketing decision more than anything else). Use this decision to determine which assurance components are going to be included (dependent on the scheme, of course): this grid is found on page 231 (table 24) in Appendix E of CC Part 3. (For your situation, you are only interested in the ALC (Lifecycle) assurance class.) Then, look up these assurance components in the body of the same document. You are looking for the "Developer action elements" and "Content and presentation elements" such as ALC_CMC.2.1D and ALC_CMC.2.1C. It helps to know what an evaluator will be looking for, so I urge you to read the Common Evaluation Methodology (CEM) for the same assurance components. Based on what you find, you'll be in a better position to formulate the right set of questions. Many of these questions will be directed to your internal integration team, some will be questions about product features. As an example, at EAL4, you need to have automated access control and build integration (eg. ALC_CMC.4.4C and ALC_CMC.4.5C) in your CM system. However, you will also need an extensive "CM plan" describing how your development environment uses the CM system (ALC_CMC.4.6C). This will be developed internally.
I would find it highly unlikely that you'll find a list of products that are "CC Ready(tm)!". The reason is because CC is more concerned about the end result rather than how you get there. Therefore, a spreadsheet might be an acceptable form of configuration management system for EAL2 as long as there are policies and procedures in place to ensure it is enforced. This would not fly at EAL4. Conversely, just because you use the Bells and Whistles Source Control Management System(tm) doesn't mean you will pass at EAL2, either because you might not track all of the necessary items.