What is the best way to handle images and media when deploying? I don't want to manually (or automatically) include each media folder, because the media files could be rather large, meaning the next time someone wants to pull this project down on their PC, it would also download the media files as well, right?
When we are developing a site, we include a small number of placeholder images. These are then stored within our source control. All other media items are excluded from the source control, limiting the download.
If it is important to get the media items - then the media is downloaded from the server.
With the placeholder images, you can create new functionality and upload the amends knowing that they will work when you select the media from the deployed site.
So you create placeholder images locally, keep referencing those all over the place, then once you have deployed to the server, you go in and upload all the new ones, then replace the placeholders with the new ones?
Yes, we develop locally with placeholders. We then upload to a staging site where the client will make amends and add content to suit their needs. We then deploy this to the live site. When we deploy to the live site, we ensure we delete the placeholder images (as i am sure visitors to the site do not want Star Wars images being displayed).
May I ask, how do you do the staging part? It's bugging me that I can't think of a good way to do it. Correct me if I'm wrong:
You have a stage database and a live database. The live database is always 1:1 with stage or lacks content from stage, meaning the live database is either the same as stage or it's behind.
When you publish to live, it will mirror the two databases, so the live gets the content from the stage database.
How do you deal with images then? How do you deal with all the little things, such as media files? They have to be copied over, right?
The live and stage are individual entities. The stage is used when a new site it being made live. Once this is done, we duplicate it to the live site.
The client then makes amends to the live site. This is NOT replicated to the staging site. We make it clear that the staging site is for them to test content ideas, and for us to upload any amends to functionality. The actual content has little baring on the functionality. Out clients understand this and accept it.
However, every now and then we will refresh the staging site with a copy from the live - database, media and anything else we want to copy across. Copying this for us is trivial and takes a few minutes of time.
In essence: Content is important to the live site, not important to a staging site.
I appreciate that this may not be how you want to do things - but keeping all environments the same is a challenge we quickly dropped years back to make our lives easier.
I get what you mean and why you're doing it. It does make sense to do it this way, although it could introduce possible issues with the live server not being up to date. At least when your mindset is: Once I publish to the live server, everything should be done and ready for people to read.
For now, this is not an issue for us and we can easily keep the files in our git repository. Maybe you can answer my other question about hostnames and cultures here as we are multiple developers who can't code on the same Umbraco project due to cultures and hostnames (using the live database as well).
Not correct. The live site will always be up to date, as that is where the content is being worked on mainly by the client. They know the staging site is a sandbox of sorts.
As for code amends, we have a process that is followed, and once sign off is obtained the amends from the source control are then deployed.
Its important to accept that content and code (including Umbraco version) are separate. You shouldn't develop anything with specific media, as this could easily be amended and changed within the back office. That's why we build with placeholders, so when the client populates the site it will work with a variety of media items.
Yeah exactly. I think, I may have written it wrong. Let me rephrase it:
If the only time the customer can create new content, is when the server goes live with the code, in theory, the live server lacks the new content, until the customer creates said content. Unless the database it pushed up first, where the customer can go and publish the content, then the code is published afterwards.
I get what you mean, but in all honesty, this has never been an issue for us. If content is required to be migrated, then we would have done this for the client, but in the 7 years i have been working with Umbraco it has only really happened a couple of times. I suppose it all depends on how what is being built and how its being built.
Best way to handle media and deployment
What is the best way to handle images and media when deploying? I don't want to manually (or automatically) include each media folder, because the media files could be rather large, meaning the next time someone wants to pull this project down on their PC, it would also download the media files as well, right?
How do I go about this?
When we are developing a site, we include a small number of placeholder images. These are then stored within our source control. All other media items are excluded from the source control, limiting the download. If it is important to get the media items - then the media is downloaded from the server. With the placeholder images, you can create new functionality and upload the amends knowing that they will work when you select the media from the deployed site.
Thanks for the reply!
So you create placeholder images locally, keep referencing those all over the place, then once you have deployed to the server, you go in and upload all the new ones, then replace the placeholders with the new ones?
Yes, we develop locally with placeholders. We then upload to a staging site where the client will make amends and add content to suit their needs. We then deploy this to the live site. When we deploy to the live site, we ensure we delete the placeholder images (as i am sure visitors to the site do not want Star Wars images being displayed).
Haha that's a good point ;-)
May I ask, how do you do the staging part? It's bugging me that I can't think of a good way to do it. Correct me if I'm wrong:
You have a stage database and a live database. The live database is always 1:1 with stage or lacks content from stage, meaning the live database is either the same as stage or it's behind. When you publish to live, it will mirror the two databases, so the live gets the content from the stage database.
How do you deal with images then? How do you deal with all the little things, such as media files? They have to be copied over, right?
The live and stage are individual entities. The stage is used when a new site it being made live. Once this is done, we duplicate it to the live site.
The client then makes amends to the live site. This is NOT replicated to the staging site. We make it clear that the staging site is for them to test content ideas, and for us to upload any amends to functionality. The actual content has little baring on the functionality. Out clients understand this and accept it.
However, every now and then we will refresh the staging site with a copy from the live - database, media and anything else we want to copy across. Copying this for us is trivial and takes a few minutes of time.
In essence: Content is important to the live site, not important to a staging site.
I appreciate that this may not be how you want to do things - but keeping all environments the same is a challenge we quickly dropped years back to make our lives easier.
I get what you mean and why you're doing it. It does make sense to do it this way, although it could introduce possible issues with the live server not being up to date. At least when your mindset is: Once I publish to the live server, everything should be done and ready for people to read.
For now, this is not an issue for us and we can easily keep the files in our git repository. Maybe you can answer my other question about hostnames and cultures here as we are multiple developers who can't code on the same Umbraco project due to cultures and hostnames (using the live database as well).
Not correct. The live site will always be up to date, as that is where the content is being worked on mainly by the client. They know the staging site is a sandbox of sorts.
As for code amends, we have a process that is followed, and once sign off is obtained the amends from the source control are then deployed.
Its important to accept that content and code (including Umbraco version) are separate. You shouldn't develop anything with specific media, as this could easily be amended and changed within the back office. That's why we build with placeholders, so when the client populates the site it will work with a variety of media items.
Yeah exactly. I think, I may have written it wrong. Let me rephrase it:
If the only time the customer can create new content, is when the server goes live with the code, in theory, the live server lacks the new content, until the customer creates said content. Unless the database it pushed up first, where the customer can go and publish the content, then the code is published afterwards.
If that makes sense. No big deal at all though.
I get what you mean, but in all honesty, this has never been an issue for us. If content is required to be migrated, then we would have done this for the client, but in the 7 years i have been working with Umbraco it has only really happened a couple of times. I suppose it all depends on how what is being built and how its being built.
Yeah, as I said: It's not that big of a deal. Thanks for the help though! :-)
Its the nature of the beast that is Umbraco - so many different ways of doing things, and a flexibility for different build types.
is working on a reply...