I'm corrently setting up our company DTAP environment for our ASP.NET web application. Current setup is like this:
Dev - on local machine with local developer db
Test - on our local company server with local company server DB
Acceptance - Production machine in separate IIS application, running a copy of production db
Production - Production machine on production DB
I want to add another environment in order to be able to reproduce bugs related to the data in the production db. I'm deploying everything using TeamCity and I'm looking for the easiest solution to download the production database (or a backup of it) to our company server and use if for a 'test on live data' environment.
What would be the recommended way to do this?
Right-click the database on the target server - "Tasks" - "Import data".
Specify your production server/tables as the source.
Related
I have now a working Website that I have deployed to the IIS on my local machine using Visual Studio 2013. I can access the website successfully from other machines in my office and in neighboring offices. I have even had others check the access from geographically remote locations, and still been successful. The access method is to put my machine's IP Address and add the name of the application, ###.###.###.###\name, into the address bar of a browser.
The next step is to promote it to production. We are not using Azure, so the tutorials for promotion to production I have found aren't useful, nor are we using 3rd party providers.
The method I have conceived is as follows:
Have an admin directly login into a company server
install the database software
install Visual Studio
install IIS
copy the local machine's db to the server db
copy the locally deployed files to the server
admin login into Visual Studio
deploy the site on the server in the same way it was deployed on the local machine
use the server IP or update the host file on all networked computers to map the IP to an appropriate name (or the local network has a local DNS we can update)
This would allow me a DEV environment (the VS IDE), a TEST env (locally deployed version), and a PROD env (the version deployed on the server).
I don't see any reasons why this wouldn't work, maybe a bit tedious, but workable.
Is this method ok? Am I missing anything critical?
No, this is an altogether inappropriate way to push a build to a production environment.
Your source code should be stored in a source code repository. You should have an automated, continuous build server pull from the repository and complete the build in a dedicated environment that is itself under change control. The build should include the generation of installation files, e.g. a click-once deployment package. From there you can have an admin run the deployment package, or, ideally, you'd push it automatically with a tool like Octopus.
The above, honestly, is the bare minimum for a commercial web site. There is much, much more you can do to make things even more robust, e.g. blue-green deployment.
Note that none of this involves installing development tools like Visual Studio on your server. The server should stay as clean as possible, running the fewest applications that you need, to minimize any sort of attack surface and to keep the machine running efficiently.
Dont Put Yours Machine IP, Decompilers Can Take It And BruteForce Your IP To Remote Acess Your Machine.
I have a website I'm developing that uses an SQL Azure database. I want to be able to test my website using a database locally hosted on the debugging machine so that my designer can work on style and content without having to deal with the overhead of firing up the Azure emulator and communicating with an external service as he is often in areas with no-connectivity.
I imagine it would be possible to extract the .sql scripts to create the database and execute them every test run, but this seems tedious. Similarly I'm not sure what the best way to configure these deployment details would be in order to switch between development, and published configurations. I'm a new web-developer cutting my teeth on a rather large project.
Using ASP.NET MVC4 and have MSSQL 2012 installed for what it's worth.
You can export your SQL azure database as .bacpac format and then import it into your sql server database. It will create all tables and fill with data. You don't need to do it on every test run, just do it once and you will have proper database for debug needs.
Switching between debug and release (or you can rename it if you want, e.g. Local and Production) configurations and using different web.config (or config transformations) is a good way to work with different settings.
If you want to store your db scripts (db structure or data) in your VCS - you can use Entity Framework migrations (new fancy way) or separate project of "SQL Server database" type (old school but proven way :) ).
Also EF migrations allows you to easily recreate db (with different name) on each run (for unit testing purposes. And then you can use SQL Express file instance (keep in mind that it's only for local work, your designer wont be able to access sql express instances afaik)
I am stuck with a problem that I could use some feedback on to solve it in the best possible way.
The issue revolves around source control -> automated builds -> deployment. Basically ALM (Application Lifecycle Management).
We have a product – an ASP.NET Web application with a MS SQL database. This product is running on hundreds of websites with associated databases across multiple virtual machines in our production environment. At the moment the web applications and database are running on servers with IIS 7 and SQL Database Server 2008 R2. The product itself is source controlled in Team Foundation 2012.
For years the release of new versions of the product has been once or twice a year for years. Now we are going to focus on releasing more frequently and hence we need a strategy for the ALM for the product.
The deployment strategy now:
In the development period between the releases, the SQL update scripts has been created manually – each time a database change was made a script was updated. When the application is ready to be deployed it gets compiled on a developer machine. The database with all the changes used would be backed up into a .BAK file. The web application, the .BAK file and the update SQL script would be packaged (.zip) and uploaded to the production environment ready for deployment.
Update existing running products:
Copy/paste the web application in the target website physical folder.
Update the web.config file – connectionstring and application
variables. Run the update script via SQL Management Studio
This would be done for each and every customer – hundreds of times.
This is a very tedious and error prone task and I don’t like it at all!
What I would like to do instead is;
Source control the database as a Database Project in Team Foundation
Automatically build the web application with Team Foundation 2012
Build Server.
Deploy the output from the Build Server to the multiple websites of
the production environment along with automatically generated SQL
update scripts run against the SQL Server.
I have been googling my ass off - only finding bits and pieces regarding builds, deployment, automatic SQL update script etc.
What I think is partly the right direction is to source control the database and use the TFS Build Server. I am very confused on how to do the deployment itself in an easy and controlled way using the output from the TFS Build server.
Ideally I would want to the TFS Build server to create a package with the latest version of the Web application, the latest version of the database, post deployment script including an auto generated SQL Update script from the previous build to the current build. This could be contained in e.g. a nuget package. Then I would want to be able to create an additional web application which should manage the deployment – target, version, iis website, sql server, web.config connectionstrings etc.
Does anyone have any advice on how to achieve this? How do you do this?
You can use a release management tool to do this, no need to create an additional web application.
One such example is Deployment Manager, from Red Gate. (Disclaimer: I work there.) It has built-in deployment actions for ASP.NET apps and SQL Server databases. The command line tool RgPublish.exe can be used to create a package for the web app as you describe from TFS Build. The same can be done for the database using the sqlCI.exe command line and associated NANT/MSBuild scripts.
The same packages can then be deployed to each of your servers. You may run into scalability issues with 100s of websites though.
The database deployment works by generating the upgrade script automatically, though you can change the behaviour to put the upgrade script in the package, when the package is first built. These are called "dynamic" and "static" upgrade methods respectively.
I am working on a web application which have two parts.
1) One is the online web site at online server.
2) The second is running on local machines/computers.
The structure of database is same on both live and on local. Now a user can make changes on the local database and then publish them on to the live server.
How can I update data from local database to online database? Which is the best technique to do this?
Use Any of the Version Controller tool like TFS, It would help in check in your changes
I have well developed an ASP.NET website with SQL Server 2000. How can I drop it on a server?
You might find these resources helpful:
ASP.NET Web Site Project Deployment Overview
Deploying a Database by Using the Database Publishing Wizard
How to: Deploy a Database With a Web Application Project
Depends on a number of things (e.g. if you have direct access to the server(s)). I tend to export my database structure as a SQL script and execute that against the production database. I then "publish" the site using VS and copy it across to a virtual directory on the web server.
If I am passing the application to a customer, I tend to use WiX or a VS deployment project to wrap the application up in an installer.
You can use SQL Server Publisher (free) wizard for moving database from development machine to the server. Or you can use SQL Server database schema synchronization tool by Red-gate.com
And SitePubisher for deploying files over FTP (and VPN)
There are many ways to do this.
Read this - http://www.beansoftware.com/ASP.NET-Tutorials/Deploy-ASP.NET.aspx