I did the following steps:
I have created a new Umbraco instance by using the nuget package and visual studio.
I have deployed to Azure, using Azure DB as backend.
Installed the articulate package.
Added my project to version control (including App_Plugins folder, articulate dlls and so on).
I am able delete the umbraco installation and I can restore it completely from version control including Articulate.
Now I am starting to add content, articles, pictures and so on.
Think I do not need to backup the whole folder on the web server. I am doing regular backups of my Azure DB and I need some folders which are also filled with new content, like
media (filling with pictures which I am adding to my articles)
App_Plugins (keeping installed packages in umbraco)
App_Data/packages (file directory for installed packages)
App_Data/umbraco.config (keeping some content for Articulate)
So, is this everything I need to be able to restore the whole system by using the version control part, azure db backup and the listed folders?
Ideally for data/contents you should backup media and App_Data folders. However, if you want to backup Umbraco site (including cache files) then I would recommend App_Plugins, App_Data, Bin, Config, Umbraco & Umbraco_Client folders.
Hope this information helps!
Basically I follow the approach as described in the question. I have added the following files and folders to the Visual Studio project and then later to version control (I have just expanded the more interesting folders which are not part of the project file by default, but needed when you redeploy the solution from scratch):
As described the backend is hosted on Azure SQL.
Open Live Writer makes it very easy to host article content on another ftp server.
By following this approach it is very easy to redeploy the complete solution, e.g. for umbraco upgrades or major changes on the site.
Related
Trying to start from Timber but the solution won't load without a site on IIS Express existing. Further the contents of the downloaded zip file, while working, the solution does not come with a way to deploy to a new zip so I can create a new zip and deploy. There seem to be files in the zip that are not in the solution so I'm concerned I might not end up with same result just zipping up the files in the solution.
Trying to download the Skeleton but no links to actually download from the app store?
https://virtocommerce.com/skeleton-theme
Starting from the VirtoCommerce.Storefront project.
Copy the contents of the App_Data/Themes/Default folder to a "theme" directory in a new directory.
Create a git repo from the root that contains the "theme" folder.
Add a GitVersion.yml file to control the versioning.
Running in Azure using blob storage you can create a CI process to automatically upload your theme when changes are checked in.
Lastly login to the platform, navigate to the site you uploaded to and activate the new theme. This allows you to fall back if needed.
Zip File
You could also zip the contents of your repo up as well.
The zip file should have a folder in it like "ThemeName-0.0.0", within that folder should be the assets, config, layout, locales, snippets, social and templates folders.
Upload that in the store of your choice and activate.
I'll suggest to use default storefont theme as base theme for customization and educations.
I'm providing some helpful information for helping you to better understand some technical moments related to working with the VC themes:
How theme resources resolving process works:
How to develop custom theme and what technology stack for this use:
Local running pre-compiled platform with installed modules
Local storefront fork (pre-compiled or from source code if you need to future customization)
For case with single theme you might directly change default (global) theme which contains in storefront project App_Data/Themes/default or make separated GitHub repository which will contain only theme and static pages files (as we made for our main site virtocommerce.com theme) and link folder with theme to storefront App_Data/Themes/{store name}/Themes.
Edit theme files in Visual studio code or any other preferred IDE, all changes will be immediately reflected to the local storefront, thanks to the cache invalidation based on theme folder file changes watcher.
Deploy theme changes to staging or productions environment by using any of
convenient CI processes. We are use Jenkins server and Azure Deployment.
Change theme files from manager UI not recommended because you will lose history of changes. And you should use this way only for emergency fixes or for debugging purposes.
I am running Joomla 3.1.5. I have a custom component installed and I have made some minor changes to some of the files. How do I create an uploadable/installable zip file to install these changes to my production Joomla site?
Please disregard the discussion on templates in the comments above.
You don't need to rename your component it seems.
If you need to install on a single site:
on the prodution site, install the installer you first installed on
your development site
sync the files with a version control system
such as git / rsync / scp / sftp / ftp whichever you're most
comfortable with
If you need to install on multiple sites:
You need to repackage it, and add to the xml manifest any files/folders you added.
Simply explode the original zip installer somewhere on your drive, and figure out the folder structure (could be admin,site,media for example).
For each browse the custom_component_name.xml section and ensure it contains the files you added, if any.
Then copy the updated files over the folder structure, zip it, and upload it to production.
Once you do this the component will be registered in the other Joomla installation. You can also keep the copies aligned between the two servers with a code versioning system such as git.
If it's a component you plan on distributing, create a script to package it, look at the Joomla docs there's plenty of info, you could use a bash script, phing, ant, maven, choose one that suits you any will do the job
I have the following setup:
Main Website - MVC 3 project, to be hosted on www.domain.com
Intranet Web App - MVC 3 project, windows authentication, hosted on admin.domain.com, which is only accessible from within the local subnet.
CDN Website - A simple web app that merely serves images to both of the above. It will be hosted (publically) on cdn.domain.com, when we go live. I have set up a local project to mock the CDN during development.
I've written a business layer that allows users in the admin panel to upload images, which are then physically saved to the CDN path that's configured (currently on the local machine i.e. C:\Code\SolutionName\CDNProject\images). The main website then uses the same business layer to find and distribute the images via http://cdn.domain.com/images/. http://cdn.domain.com is currently set to http://localhost:55555, while we develop.
Whenever an image is created via the admin panel, it is physically created on disk. Each developer works on his own machine, we we want to be able to check these files in to TFS, for the time being. As you might have guessed, adding files to the file system does not automatically reference them in the project:
I thought there may be some way to reference these images as resources, or set a directory to a "content" directory of sorts... but I can't find anything.
Some developers work remotely via VPN, and do not have access to the local network (only TFS), so a network path is not an acceptable solution.
I thought I might be able to set a pre-build event up, to add all files in a directory to the project?
There is no very easy way to do that. There are a few ways to think about:
1) Write VS adding which adds new files to project (via DTE - starting point). Find out how to automatically run this VS addin on Pre-Build step. Install this addin to your developers machines.
2) Extend your admin logic to automatically check-in the uploaded files to TFS via TFS API
3) try to apply more sofisticated techonologies like this one: T4 Tutorial: Integrating Generated Files in Visual Studio Projects
Hope that helps,
Visual Studio project files have an XML syntax. Project file properties can be modified in a simple text editor (files added/removed, etc.).
You can create a script to open your solution, and before actually opening the solution, you can scan that directory and "inject" the files (with the appropriate XML tags) in the project files.
I don't think you can add this as a pre-build event because the project files are already loaded at that point, and you cannot modify them while they're used.
I'm using Publish/Web Deploy to deploy an asp.net aplication from Visual studio 2010. It works perfect, but there is a problem. If the new release is not working as expected, the old version is already replaced by the new one and there is no easy way to roll back to the working version. How is this best solved? I wish it was possible to keep the old version on the server so I could just switch back if needed.
With WebDeploy there is no built in rollback feature, so once you've deployed that's it.
There's a number of hand rolled strategies you could put in place, for example:
Limited Access e.g. Shared Hosting:
Where you don't have full access to the machine -
Backup the live site beforehand by downloading it.
Keep copies of what you deployed so you can push the previous version should something break
Full Access:
Maintain two sets of folders for the application and map your site to one or other of these folders. When you come to deploy switch the IIS site's physical path to the other folder then deploy. If the site fails then just knock the site back to the original folder. Each successful deploy would alternate between these two folders.
For stuff like user uploaded content you'd need to map virtual directories to a place on the file system that's always the same place because you don't want to be copying these around each time.
You're not the only one who has encountered these issues. Have a look at this article by Rob Conery and his observations about the state of affairs regarding ASP.NET deployment.
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Using some form of Source Control would be another alternative. We use subversion, so if the publish goes bad, we can just update back to the last-good revision, and publish that. Even if you're the only developer, using source control can be very useful.
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.