I'm a web developer thinking of moving work on our largest client's site to a Git workflow, but I am new to Git and am not sure how to integrate it with our client's .NET servers and IT folks.
The current workflow is: a co-worker and I work cooperatively on local versions of the site files, which we then push via FTP to the client's development server (accessible via VPN). Once the changes on their dev are approved, we have to catalog every changed file and email that list to our client's IT team. One of their team then manually pushes the changed files from dev to their production server. We are not allowed any access to the production server, as there are enterprise apps on it as well as the public-facing web directory.
A bit more awkwardness comes from the fact that the client's IT guys are all .NET developers and we are a Mac shop. Fortunately, the site files are 99% HTML/CSS .aspx files, so they are easy for us to work with. Occasionally, the IT guys post an .ascx form control we have to incorporate, but for the most part changes travel from us to them.
As the site has grown, the labor of cataloging changed files has become a bottleneck and a point of potential failure. I want to automate deployment and provide revision tracking and rollbacks. From our side of the router Git looks like the way to go.
But what do I propose for the client side of the workflow? My understanding is Git is not native to .NET or IIS. I doubt I will be able to persuade our client's IT guys to install and use a new toolset. Their main job is enterprise app development, and I get the feeling they don't exactly live for the thrill of pushing our web updates live.
I am not sure if i understand you right. But git with .NET is pretty much the same as in other technologies.
Here is a git extension to use with Visual Studio:
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
Github is full of .NET projects.
I can't give you a advice to how to propose it. But git is definitly not a problem to use in VS or generally in .NET. They just have to switch.
You can also integrate git in your Team Foundation Server.
http://www.microsoft.com/en-us/download/details.aspx?id=30474
Git-TF is a set of cross-platform, command line tools that facilitate sharing of changes between TFS and Git. These tools allow a developer to use a local Git repository, and configure it to share changes with a TFS server. Using the tools, changes made in TFS can be pulled into a local Git repository, and changes made in the Git repository can be checked in to TFS. These tools can be used by individuals or teams collaborating using Git.
This way you could use both. TFS and Git for the same project. I think this could be a solution.
Related
I have just taken over the management of a business-critical WordPress site.
Currently there isn't a development server or any source control. I would therefore like to get this setup and was just after a bit of advice on the best workflow.
Development will be done on one machine initially, but the development server must be hosted so geographically dispersed stakeholders can view the site and sign-off changes before it is deployed to the production server.
I have used Subversion previously, but I would like to make the jump to Git and was thinking about using a private Bitbucket repository.
My questions are:
Does this sound like a sensible solution?
What is the most efficient/robust method of getting the code from the local machine to the production server (via the development server) while maintaining version control?
Many thanks!
Yes you can do the development initially on your local machine, commit the changes, push them to the bitbucket with Development branch. You can have read only access to your stake holders in order to sign off the changes from Development in the remote to Production in the Remote branch.
Since you used SVN before and trying to migrate to GIT. You can use the git svn command to migrate from SVN to GIT.
Or you can use the tool SubGIT tool for a stress free migration from SVN to GIT.
I don't know if this is possible, but I am trying to open a Visual Studio 2010 solution that is on a remote server from in Visual Studio. The project I am on is using Kentico CMS and we would like to be able to sync changes made to the hosted site (on the server) using TFS and Visual Studio as well as changes made via the Kentico CMS Desk portal. I haven't found anything on the Visual Studio or Kentico dev site or in the documentation. Whether or not this is possible, or if there is a better way of achieving this goal, I would appreciate any insight you could give.
I believe this system would help you accomplish syncing your development environment to a remote server.
http://www.kentico.com/Product/All-Features/Other-Modules/Staging-and-synchronization
You can check out what gets synced on this page:
http://devnet.kentico.com/docs/devguide/index.html
The content staging is good for synchronizing changes made via the user interface.
For synchronizing changes in the file system (e.g. changes in the code files in Visual studio), you can use some third party tools to keep the folders up to date - i.e. Drop box or Google drive (but there are also other tools and utilities).
After talking with a couple developers who were a bit more familiar with Kentico, we eventually found a good solution to our problem. It's not perfect, but it will work for our purposes.
We had the Kentico administrator generate a new license code for Kentico for 'localhost'.
In Visual Studio, we pulled down one of the default Kentico projects from the server.
On the project properties, we set Use Dynamic Ports to false and chose a number to set the ports to.
Once the project was built and running, we could navigate to 'localhost:1501/[ProjectName]/[PageName (CMSDesk, Landing.aspx, etc.)]' to access the CMS Desk portal.
In the CMS Site Manager, navigate to Sites > (click the Edit button for the site) > Domain Aliases > New Domain Alias and set a new domain alias (the website you want to use when viewing the site (for us it was dev.[projectname].com). This allows other developers to log onto and use the pages via the domain alias when the project is on the server. Changes made on the localhost copy must be pushed to the server before they are visible.
Using the local copy, we could work with the web parts and sync changes to TFS. We still have to manually copy the project from our local machine to the server in order to deploy, but we are hoping to set up a build machine that will push the TFS build to the server on a regular basis, which shouldn't be especially difficult.
If we find any better way to achieve this goal, or find any potential problems, I will be sure to update.
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
I'm working on a fairly new project and we started from scratch. So not only the web application itself needs to get developed, but also the whole process of publishing the site and configuring the web server etc. need to be done from scratch.
This question might be more apropriate for serverfault, but that really depends on the answers. So, let's give it a try.
Wehn ever I publish our site via VS2008 (right click on the web site, publish web site, wait... done) I need to somehow tweak the process and trigger some other tasks, like:
- Copy some folders from my dav machine to the web server
- Delete the test database and let some scripts run on it
- and maybe some more I'm not remebering right now.
I was reading about the most obvious solutions like MSBuild, Powershell and VSTS2008, but I don't really want to dive deep into them until really I know, that theses tools can actually solve my problems. So guys, I'm pretty sure a lot of you have got a lot of knowledge about these tools or know even better ones. Please let me know. I really appreciate.
Thats my environment I'm living in:
- VS 2008
- VSTS 2008
- SQL Server 2008
- Windows Server 2008
UPDATE: Thanks for the great answers so far, but I'm especially looking for a solution integrated into Visual Studio Team Foundation Server as we're already using it for Source Control.
Cheers,
Steve
We deploy our web application with Subversion, and are very happy with it.
The build server compiles the application, copies it to a deploy directory and checks in changes to a Subversion repository. Okay, I admit that this is not trivial, but it's worth to invest here... because on the server(s) the deployment is now extremely easy. Advantages are:
Only the necessary files are copied to the server, the downtime is minimal (using svn update)
It's a piece of cake to verify what version is deployed to the server, and it's easy to have a consistent version across multiple web servers
If you screwed up, it's just 2 clicks to revert back to the previous version
It's takes care of deleting files when you deploy a new version. Copying a web application over an older version can leave potentially dangerous files
Modifications in the web.config are not overwritten by the deployment, they are merged. That's really a big plus
You can set pre and post build events, and can have one the events fire a script to complete your tasks.
You might look to see if the IIS Web Deployment Tool fits your scenario; it allows you to publish your website, configuration settings, database, etc... all together. This will also be integrated into Visual Studio 2010.