First of all, familiarize yourself with Deploying Customizations Across Microsoft Dynamics AX 2012 Environments, where you'll learn important concepts like object IDs, model deployment, modelstore deployment etc., as well us Microsoft recommendation how to manage the whole process (e.g. using model deployments to test environments and the modelstore for production).
The final decision is up to you, but let me give you an example of a process I used when still working with AX 2012:
Developers work on a shared environment connected to Azure DevOps. What Microsoft supports is having a dedicated environment for each developer, if you want a shared environment with Azure DevOps, you need some customizations.
An automated build downloads source code from Azure DevOps, builds the application, assigns a model version and exports a model file. Unfortunately, you won't get any build pipeline template of anything from Microsoft. You need to do it on your own (with the help of some community tools), or you buy and extension of Marketplace.
A release process takes the model file and installs it to a test environment.
When tests are successful, the same model file gets installed (by a manually triggered release) to a pre-live environment for final verification.
If final testing is successful, the complete, compiled application is propagated to production by a modelstore deployment.
The pre-live environment uses the same objects IDs as production. The other environments may have different IDs. This plays a role also when you refresh databases etc.; refer to the aforementioned document for more details.
You don't necessarily have to have everything automated; that's more for inspiration. The key is that you need to decide how you'll use which environment and do deployments and data refreshes accordingly. It's also important to know how long production downtime you (your customers) find acceptable (which influence what options you have for PROD deployments).
Also, it may happen that some objects (like security elements) get created in USR layer in production. You need a plan what you'll do with them.
Subra's statement that you should use .xpo files for deployment if you have a single AOS doesn't make sense to me. It has two main problems. You'll basically develop a new version of your application in production, which isn't safe. You should test the application in a different environment and then move the exact application you tested to production. The second problem is that you'd have to compile the application in production, making your PROD unavailable for a long time. Whether you have a single AOS or more of them doesn't make any difference. Also, I don't think that there shouldn't be any production environment with just a single AOS.
