SQL Server Team-based Development - Red Gate Software

Chapter 4: Managing Deployments
You'll need to open the properties for all the projects and set the connection string for
each one. Once you've completed these edits and saved the solution, you're done, and the
Sandbox_MyApp project is ready for deployment. Simply check the latest code out of
source control, set the configuration to the server to which you want to deploy, and run
the deploy process.
Shared development
At some point, you'll have new functionality completed in your sandbox environment.
You'll have synchronized it with source control, and possibly applied a label or some
other determined version. It's now time to make sure your code works properly with
the code developed by the rest of your team, before releasing it to the Staging team. In
this example, I've referred to this environment as the shared development (or common
server) environment, to make it clear that you may expect changes to the code base in
this environment.
This deployment is usually scheduled, but could be on demand, depending on your
processes and the needs of the development project. In either case, your goal is an
unattended, automated install, rather than something that requires a lot of manual effort.
To deploy to the integration server, you need to set up a new server project (Development)
and a new compound project (Development_MyApp) within the solution. Once
these are completed, you can create custom security logins for the server project. You can
also add environment-specific roles and privileges to the compound project, independent
of the server roles and privileges, if needed.
With the projects created, you can then create a new Development solution configuration,
as described previously. This time, you'll have five projects in the solution, as shown
in Figure 4-6.
102