This is a great topic and I will be interested in the other responses. Here is our practice.
We use Tortoise SVN for our source control and work in 30 day cycles for development. We start each cycle by creating a new branch in source control which we name after the months. ex 2016.1.1 for the current cycle. We then check out our working files to our local computers for development work. We have 3 active developers and a manager overseeing production with access too. The three developers try not to work on the same specific areas in the application.
So developer one modifies local code and then updates to source control, several times per day. We try to insure we have the latest updates from source control at the start of each development session. Sometimes we have to use the merge function in the source control software if we accidentally work in the same area of the application concurrently.
When we have completed development and QC tested, it gets uploaded to a QV Test Server for an outside team to audit the app through the Access Point. As issued are discovered, the process cycles back to production until all are resolved and we are ready for production. We source control all SQL stored procedures and views in the same way.
The test server usually only has a small subset of the data for the first round of QC testing. However, we have recently started doing a full load for the final QC. This insures that we have QC'd the whole model and also allows us to just copy a QVW file to the production server when all are satisfied with the quality.
This works for us as our data is static and on a 30 day refresh cycle. We then start the process over again. We have a meeting on a weekly basis with stakeholders and business analysts to discuss the next round of enhancements / bug fixes.
Hope that helps and I look forward to seeing what everyone else has to offer
Our process is similar to Mike's
We have 2 environments - dev and prod.
All of our development is done in our dev environment and we use include files to specify unc loctions of various files and locations. The files exist in the same loction in our dev and prod environments so when an applciation is moved from dev to prod, no coding is required or different versions of the applciation for input or output locations.
Once the application development is completed, we follow a process that identifies testers, product owener etc -once approved, the application is placed on dev sharepoint for testing. Once testing is complete, the applciation qvw is moved to the production server and then placed on production accesspoint.
Once an application is placed on production accesspoint it is removed from dev accesspoint unless it is needed