I've been trying to use SVN to deploy my asp.net site to production. My workflow is:
Setup:
Publish Site to FolderX,
Import FolderX to SVN,
Update web server production folder with the repository for FolderX.
Everyday:
Publish updated site to FolderX,
Commit Changes,
Update remote server with changes.
That's the theory, but when I publish the site again to FolderX, it destroys the .svn folders that are inside all the site subfolders.
How can prevent that from happening?
Well, a couple of things:
First, why does it matter if the .svn folders within the website are ruined? Surely you're not committing FROM your production environment back into SVN? I suspect the problem you're having is later updates. You can solve that particular problem by deleting the entire site before you update into it.
Second, why are you trying to use SVN for deployment? That's not really what it's for, and all it would take is about 5 lines of batch code to deploy your entire tree to the production location.
If you're using tortoisesvn, then click 'use _svn instead of .svn directories' in the settings.
Then the publish hopefully won't ignore the .svn directories.
Related
Using Azure Build Pipelines i'm trying to publish an ASP.NET WebForms website to IIS.
Everything works, except that I have several images in a folder of my website (e.g. /Images/1.jpg,2.jpg, etc..) and I would like to delete all images from that folder except 2.jpg and rename it to 1.jpg after I've deployed the website (or during the release pipeline if that's possible)
Is there any way to do this in Azure Pipelines?
Here you can take a look at a Catalog of the built-in tasks for build-release.
The Delete Files task states:
"Use this task in a build or release pipeline to delete files or folders from the agent working directory".
This may give you some ideas on how to achieve this.
I hope this help.
Comment on:
The Delete Files task states: "Use this task in a build or release pipeline to delete files or folders from the agent working directory".
and
".. from what I just tried, this can only delete files inside the artifact and not on the IIS Server."
That is correct for default behavior, but it has a parameter called SourceFolder, which has a default as "$(Build.SourcesDirectory)". When you specify the SourceFolder to be "C:" you can enter a pattern to delete anything on the server. Might be wiser to use a bit more elaborate path then just c:\ but it works. Just tried it on a pipeline where a file needed to be deleted not from the workingfolder but from the deployed IIS location.
PS in a release pipeline the default seems to be the $(System.DefaultWorkingDirectory) and not the $(Build.SourcesDirectory). Whether that is because the Build.SourcesDirectory defaults to System.DefaultWorkingDirectory in release pipelines or the task is being smart I don't know.
Want to cut to the chase? Jump down to QUESTIONS below. Cheers.
BACKGROUND
I am changing my web development workflow to include GIT for version
control. GIT is new to me, although I have a technical background, so
it's not a complete mystery. :-)
I have a GIT repository on Bitbucket (BB), which I use as the central project container.
I use my local web server (on Mac OS X) for development.
That's my dev server.
Once tested locally, I push changes from my dev server to Bitbucket.
I have two remote servers. One is a staging server, the other is the production/live server.
I've learnt (sufficiently, for now) how to manage the files between dev and Bitbucket. I have everything set up to run over password-less SSH (using rsa keys).
THE ISSUE
I am not sure what the proper or recommended way is to manage the workflow between BitBucket (or whatever system one uses) and the staging server, and production server.
Here's an example:
I am working on a site with the following structure (in part): (those with ++ around them are the folders I with files I must track/manage in GIT)
- www_root/images/...
www_root/etc/...
www_root/extras/themes/...
www_root/extras/plugins/...
++ www_root/extras/plugins/my-plugin-1 ++
++ www_root/extras/plugins/my-plugin-2 ++
++ www_root/extras/themes/my-theme-1 ++
www_root/extras/theme/someothertheme
The approach I took on my dev server (localhost) was to have a repository for the entire www_root/, and a gitignore that excludes everything except those folders with the ++ next to them (in the above example), AND their parents. So in this case, the ../plugins/.. and ../themes/.. folders are both included in full.
When it comes time to set up the staging server, this is where I came unstuck. What I did was install the application on there (WordPress, in my present case). But then I can't add the GIT project, because I run into the issue that git init aborts due to the folder not being empty.
As mentioned, on my local server I'd set up the site root as the root of my project, and with gitignore all files except the various folders I am working in, are excluded.
WHAT I TRIED
I attempted setting up a project.git folder above the web_root, and then adding a work-tree for the /extras/ folder in the web root. I ran into issues. Could not git init (non-empty folders issue) and could not git pull, git fetch, etc.
I also attempted creating a GIT project within the www_root, and with the worktree being the /extras/ folder, but again, struck the non-empty folder issue.
QUESTIONS
1) Is there a way I can incorporate a GIT project, and pull down the files from Bitbucket/Github, into a an existing folder structure (such as would exist in any situation where one is developing components of a larger application, with its broader folder structure)?
2) OR, is it necessary to either have a completely empty /wp-content/themes/ (in my example) folder on the staging and production server, and manage the entire content through GIT, and then GIT INIT and GIT CLONE into that folder, and then have a separate project for /wp-content/plugins/ where all content of that folder is handled through GIT, etc., and do the same for that?
3) OR, is the best approach to have separate projects for each sub-folder? Hypothetically, www_root/extras/themes/my-theme-1 and, let's say, www_root/extras/themes/my-theme-2, and perhaps www_root/extras/plugins/my-plugin-1
4) Or have I completely overlooked another way of going about this?
If this is an option, can you create a new folder, create a GIT repo in it and then move files into the repo?
Then the usual - in case of fire:
git commit
git push
leave the building
I'm using asp.net and WebDeploy to publish the latest bits of my website. The production site has a couple folders that I would like to keep in sync, though.
Since it's an asp.net site, I would rather not have my entire repository on the server when I can get by with just the views and dll. Additionally, I would rather not add the extra clutter of additional class projects & files to my production server file system.
How do I keep the folders in production in sync with the master branch in git? An automated solution would be optimal.
you could create a git hook that will export your files using git archive to create a zip (or tar) to a tmp folder. Then, uncompress the files to the given tmp folder, finally, transfer them to your server.
Also, check this answer Do a "git export" (like "svn export")?
Setting up a scheduled task to commit those files to their respective git repositories will work. It's not ideal, but it will make sure those repositories are relatively up to date with the assets on the live site.
Does anybody have an idea how to use he "publish website" command on VS 2008 and be able to track changes so as to only sent to the hosting server the modified files?
When the command is called, the destination folder files are wiped and replaced with the result of the new build (assembly file are created as well as some marker files).As my website is getting bigger and bigger I have to transfer to the server all the assemblies in my bin directory and keep in mind which other files I may have modified.
Is there a better way of doing this?
ps: I use FileZila to transfer my files to the server.
Publish to a local directory, then use a diff tool (such as WinMerge) to find and copy the modified files to the server.
You can publish locally and use any mechanism of your choice to transfer the files.
Have you tried Website->Copy Website menu item? It seems to know which files are changed.
I am experimenting with using subversion to deploy updates to my ASP.Net application, one issue that I am facing is that whenever the working copy(containing the build) is updated the ".svn" folder inside of bin gets updated and this causes the ASP.Net appdomain to recycle. I don't want this to happen unless something in bin has actually changed.
Is there a way to tell ASP.Net to ignore the ".svn" folder inside of bin? Basically not watch that folder for changes?
If this does not work out, I'll be using a staging folder outside the web folders to download the builds onto the servers and then use scripts to patch/update the actual web folders.
[Edit:] The svn export option will not keep my deployment under version control, I want to be able to do "svn update" on the web folders to deploy and rollback releases.
If you use svn export instead of svn checkout to get the files from your repository you will not get the .svn folder on your server.
[Edit] Another option would be to delete "bin" from your repository (and possibly commit it to another one, if you need revisions), and then just copy the bin-catalog to your webroot manually when it changes. Remember to add "bin" to your svn-ignore-list.
You probably want to add the "Bin" directory to your svn:ignore list; it should not be committed anyway as it contains compiled code, not source code.
In any case as your final deployment "svn export" is probably a better choice, as others have noted.
Have you thought about using a Continuous Integration server?
Continuous Integration basically refers to a development practice designed to increase the frequency of commits to the repository.
The more often you commit the better granularity you have over rollbacks and also the less that can be broken between commits.
The tools listed below all work with subversion and can be combined with MSBuild on the server to produce an automated build & deployment system.
MSBuild directives include the option to ignore certain files (i.e. code behind) when copying to live directory. In addition, some files you may want to have a development version and a live version... in this case we should write a "transform" script for MSBuild which just makes sure that the file is correct for the live server when copying live. (i.e. web.config)
Hudson - http://java.net/projects/hudson/
Draco - http://draconet.sourceforge.net/
CruiseControl - http://cruisecontrol.sourceforge.net/
Well unfortunately if you do this, then you will, as you're experiencing, an AppDomain restart. So unless you do as Espo has said and use svn export, you'll see this issue.
Would it be easier to write a 2 line batch file that svn updates a local copy and then copies the files across?
An app pool recycle should not be that big a deal. Is your issue perhaps that your users are losing their session when this happens? If so, switch to StateServer or SQLServer sessions instead of using InProc.
Subversion 1.7 and up doesn't create .svn files in each subdirectory anymore which makes it possible to do what you want without the .svn files getting in the way.
I'm a little late to the game but I'll throw my 2 cents:
You can use svn export passing a -r REV param. This enables you to rollback your app to the specified revision.
So you can use:
svn export REPOSITORY DESTINATION --force to update to HEAD (current state of you application)
or
svn export REPOSITORY -r REV DESTINATION --force to update to an other revision (maybe you should be using tags)
Don´t forget the --force param so it can replace the existing files in DESTINATION.