This has been referenced before in the links that you posted, so I will just add some specifics. Compliance testing can be thought of as a kind of QA or integration test, just like the other tests that your application(s) may have. In order to make it useful, a compliance test should fail the build in some meaningful way and guide the both developers and those responsible for operating them applications (hopefully part of the same team) what guideline is being infringed upon and how to regain compliance.
This also means that the compliance team needs to be able to write tests which make assertions on the deployed state of the application, preferably before it is deployed. If compliance is done after the deployment, you face the need to roll back or apply hotfixes.
I have found that Chef Inspec is a good tool for this job. It allows the compliance team to write profiles right off of best-practice documents. It can be kept in an independent repository, to be picked off the shelf if need be and applied to arbitrary workloads, or included in the same repository as the application. The former scenario allows global compliance testing across the entire org's suite of applications, while the latter helps to foster better collaboration between the developers and the security teams. Of course there are several options in-between.
A good example of how to write a compliance profile is available from Chef's training site.
Who should write the profiles depends on several factors, including proficiency, role and of course operational responsibility for the application. I have found that it is best when the profiles are written by a second set of eyes than those who write the deployment code. This is in the interest of keeping the audit process independent and unbiased.
As to where the compliance tests should be inserted in the CI/CD pipeline, this is often a matter of discussion, and depends on your delivery and deployment model. Others have mentioned the benefits of shifting left and this makes sense too in the DevSecOps world.
The key however is to test actual production states. Often people would use the staging environment for this, which would be a good idea if it is as close as possible to the production environment. The reality however is that certain aspects of compliance affect certain aspects of the application or environment, so it often makes more sense to inject the compliance testing into the various stages of CI/CD deployment similar to Figure 3.1 of :
Different tools come into play in different stages, and as you move down the delivery pipeline, the compliance envelope becomes increasingly complex. After deployment, you also don't have absolute certainty that the state has not diverged from what is in the codebase (people could log in and do things). At some point you should need to assert overally compliance of the application, and have it inclued as part of your monitoring system.
Having a set of compliance profiles executable as code and able to break the build makes it a bit easier to implement continuous improvement, give immediate feebdack to developers and operators, thereby shipping quality code faster. It also allows you to give concrete information to the auditors when they come knocking.
