Where I work, the design and development departments are totally separated, however we (the design department) are responsible for managing the CSS for our sites. Typically, new CSS needs to be released to the production server far more often than new website code. Because of this, we are deploying the CSS separately, and it lives outside source control.
However, lately, we've run into a few problems with new CSS not being synched for up site releases, and in general the process is a huge headache. I've been pushing to get the CSS under some kind of source control, but having trouble finding a good deployment method that makes everyone happy. Our biggest problem is managing changes that affect current portions of the site, where the CSS changes need to go live before the site changes, but not break anything on the exisiting site.
I won't go into the finer details of the weird culture between designers and devs here, but I was wondering what experience others have had in managing large amounts of CSS (50+ files, thousands and thousands of lines) that needs to be constantly updated and released independent of site releases.
I'll advocate the use of source control here. Especially if the development team uses branching to deal with structured releases. That way, whatever CSS is checked into the production branch is what should be deployed ... and if it is updated mid-stream, it's the responsibility of the person (designer?) that updates it to promote that code using whatever system your company uses to promote changes to production.
The fancy name is "Content Delivery Network" (Wikipedia).
We store our CSS files in a database, and then have a separate website that does nothing but serve CSS resources. We implemented this in May 2007 for 1000+ websites in 30+ countries. It has worked flawlessly for the last 15 months.
Static images and even JavaScript files are handled the same way.
Related
I've never worked with any CMS and I simply wanted to play with such ones. As originally I come from .NET roots, so I was thinking about choosing Orchard Core CMS.
Let's imagine very simple scenario, together with my colleague I'd like to create a blog. As I'm used to work with web based systems and applications for a business for me it's kinda normal to work with code repository, having multiple environments dev/test/stage/prod, implementing CI / CD, adjusting database via migrations or scripts.
Now the question is do I need all of this with working on our blog with a usage of CMS.
To be more specific I can ask few questions:
Shall I create blog using CMS locally (My PC) -> create few articles and then deploy it to the web or I should create a blog over the internet and add articles in prod environment directly.
How to synchronize databases between environments (dev / prod).
I can add, that as I do not expect many visitors on a website I was thinking to use Orchard Core CMS together with SQLite. Also I expect that I can customize code, add new modules, extend existing ones etc. - not only add content (articles). You can take that into consideration in answering the question
So basically my question is what should be the workflow of a person who want to create / administer and maintain CMS (let it be blog) as a single person or as a team.
Shall I work and create content locally, then publish it and somehow synchronize both application and database (database is my main question mark - also in a context how to do that properly using SQLite).
Or simply all the changes - code + content should be managed directly on a server let's call it production environment.
Excuse me if question is silly and hard to understand, but I'm looking for any advice as I really didn't find any good examples / information about that or maybe I'm seeking in totally wrong direction.
Thanks in advance.
Great question, not at all silly ;)
When dealing with a CMS, you need to think about the data/content in very different terms from the code/modules, despite the fact that the boundary between them is not always completely obvious.
For Orchard, the recommendation is not to install modules in production, but to have a dev - staging - production type of environment: install new modules on a dev environment, test them in staging, and then deploy to production when it's safe to do so. Depending on the scale of the project, the staging may be skipped for a more agile dev to prod setting but the idea remains the same, and is not very different from any modular application.
Then you have the activation and configuration of the settings of the modules you deploy. Because in a CMS like Orchard, those settings are considered data and stored in the database, they should be handled like content. This includes metadata such as the very shape of the content of your site: content types are data.
Data is typically not deployed like code is, with staging and prod environments (although it can, to a degree, more on that in a moment). One reason for this is that a CMS will often feature user-provided data, such as reviews, ratings, comments or usage stats. Synchronizing all that two-ways is very impractical. Another even more important reason is that the very reason to use a CMS is to let non-technical owners of the site manage content themselves in a fast and direct manner.
The difference between code and data is also visible in the way you secure their changes: for code, usual source control is still the rule, whereas for the content, you'll setup database backups.
Also important to mention is the structure of the database. You typically don't have to worry about this until you write your own modules: Orchard comes with a rich data migration feature that makes sure the database structure gets updated with the code that uses it. So don't worry about that, the database will just update itself as you deploy code to production.
Finally, I must mention that some CMS sites do need to be able to stage contents and test it before exposing it to end-users. There are variations of that: in some cases, being able to draft and preview content items is enough. Orchard supports that out of the box: any content type can be marked draftable. When that is not enough, there is an optional feature called Deployments that enables rich content deployment workflows that can be repeated, scheduled and validated. An important point concerning that module is that the deployment only applies to the subset of the site's content you decide it should apply to (and excludes, obviously, stuff like user-provided content).
So in summary, treat code and modules as something you deploy in a one-way fashion from the dev box all the way to production, with ordinary source control and deployment methods, and treat data depending on the scenario, from simple direct in production database instances with a good backup policy, to drafts stored in production, and then all the way to complex content deployment rules.
My Django project's team is looking to have the designer's CSS in a central place, preferably on the production server (so that there's one "truth" to the current design, a model he claims that he's worked with in the past). Assuming that this is even a good practice, it would mean setting up Git to deploy the CSS in a Continuous Integration (CI) manner to production.
However, I would want to restrict Git somehow for the designer so that he doesn't accidentally update any files other than CSS or HTML. Python and Django files would be updated by developers, who would be deploying in a more traditional manner: working in their own branches and only having a human build manager
merging everything in to master when tested and ready.
Part of the reason that we want the designer to be able to deploy the CSS to a server is to avoid setting up the Django site locally on his laptop (he's not so technical outside of CSS, HTML, and Git).
Is this setup even a good idea? If not, what's the proper alternative?
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
Is this setup even a good idea? If not, what's the proper alternative?
I have some reservations. It sounds like your designer is going to be the only person pushing changes to production without any gates: no code review, no tests, etc. Continuous integration is great, but a sane process includes safeties that prevent bad deploys. Since the rest of the team is following a different process, you'll end up managing two different pipelines. That's a waste of effort, and inevitably one of them (probably the designer's) falls apart due to lack of attention.
The alternative is put everyone on the same process. Teach the designer how to run the application locally, or build a harness that makes it easier. Unless your site is entirely static, how can they even see what their changes look like without that? Maybe it's more work to train them up, but it's an excellent opportunity for personal growth.
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
If you go this route, you can use Git hooks to restrict what the designer is allowed to commit. You can either put a pre-commit hook on their client or, if you control the server, a pre-receive hook that runs for only the designer's user. Either one can look at the committed files and block the commit/push if any are not CSS or HTML. There's a pre-commit framework called Overcommit that might be helpful to you. If you're using a code review tool, most have places you can hook in a bot to leave a comment or block the merge when they've modified a file they shouldn't have.
Another option here is trust your coworker. Presumably they were hired because they're effective and useful, so you can save a lot of effort building up restrictions if instead everyone's clear on what they're supposed to be doing and generally doesn't screw it up.
Say you have a large Web site, containing several discrete applications that run in the same site to do various things. You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.
These applications will run in the same process. No virtual directories or app isolation. They will share things like session, cache, cookies, etc.
Sure, the code-behinds and class-libraries are just DLLs in the bin folder, but what of the presentation-level stuff that has to integrate in the runtime environment? What about sharing of the code-level resources I mentioned above -- cookies, session, cache, etc.? What about base page classes?
Example: it strikes me that every sub-app needs to be "master page aware" -- it needs to know where the master page will be located, and what ContentPlaceHolders are available, because the sub-apps Web forms will need to reference this stuff.
Any other thoughts here? Assume the sub-apps will share the same master page, theme, and everything else in the presentation layer, so they appear to be a seamlessly integrated part of the whole. But they will be worked on in different Visual Studio projects, by different dev teams that know nothing about one another except what's absolutely necessary.
Anyone want to share some best practices here?
You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.
Why work in isolation? Establish a repository for the entire solution including all projects. Whatever change is made it is immediately available to all developers. With your approach it will be a nightmare to come.
Consider splitting responsibility by pages. One team does one segment, the other does the other one.
Another option is to let each team develop their part as a user control. You can easily assemble those together to represent a complete product.
I was wondering how teams that develop sites using Drupal (or any other CMS) integrate version control, subversion, git or similar, into their workflow. You'd obviously want your custom code and theme files under version control but when you use a CMS such as Drupal a lot of the work consists of configuring modules and settings all of which is stored in the database.
So when you are a team of developers, how do you collaborate on a project like this? Dumping the database into a file and putting that file under version control might work I guess, but when the site is live the client is constantly adding content which makes syncing a bit problematic.
I'd love to know how others are doing this.
You are correct that this is an issue for Drupal--version control works fine until you turn the site over to your client or open it up to users.
Your question seems like a more specific version of this one, which touched on version control in the Drupal workflow. You may find some answers there that help.
For some projects, I have exported all of the views to code, using that feature of the Views module, and I have one project where all of the blocks have been exported, as well. (Although that was a development exercise and not a customary thing to do with blocks.)
Take a look at the work that Development Seed is doing to work around this problem. They are leading the development of the Context, Features, and Spaces modules that work together to store configuration data in modules (outside of the DB) so that it can be versioned with the code.
There is a Drupal group called Packaging & Deployment for discussing the various solutions that are being developed for this issue.
Right now there are a lot of efforts towards creating something that will handle the dev -> production difficulties with drupal in relation to the database. Features, that flaminglogos mentioned is one, but I feel that is more focused on creating stand alone projects, ie ones that would be installed on many sites.
For simple maintaining you dev and prod databases I'd take a look at http://drupal.org/project/deploy and http://drupal.org/project/dbscripts. They support syncing and merging db side drupal config data.
I can't guarantee they are ready for prime time though...
There is a lot of effort of shipping the next drupal version with configuration in code. That's is the key to have it in a version system.
For now you can use the features module, with that you can export things like content types, views, etc. to code, and then compare, version and revert it as you need.
One of the projects I was in charge of as a JSP/Struts developer at my last employer was a themes tag library (present on every WebSphere server as a shared library) that let any Java web dev in the company pull in any of the standard themes like intranet, public, etc. with minimal effort. The themes included header, footer, navigation, and links to css & javascript, etc. They could even customize things a bit when we gave them the option, like choosing a selected tab.
This setup was ideal because we could make centralized change to any standard UI elements and they were automatically pulled in by all sites using themes without any effort by the site developer.
With the new job I started in December, I've switched to using ASP.NET. I'd like to propose something similar in spirit to the themes app here, since we're running a bunch of different sites that should have a unified look and feel.
What's the best way to accomplish this? I'd rather not have to recompile anything to update the theme to make this work.
Edit:
Although I was hoping for a better answer, the .NET gods apparently don't approve of what I was trying to accomplish. Here are the three options that were found:
Compile a Master Page into a DLL and put it into the GAC:
This works in simple cases, but as a hack it's too brittle. I couldn't get it to work correctly with our site.
Create a virtual directory to the Master Page in each web app: This actually does work, although it doesn't make for a very comfortable development environment. However, one of the things we are trying to move away from is having to create virtual directories inside each web application. No dice.
Create a bunch of custom controls, compile them into a DLL, and put it into the GAC: This is the answer I selected. It's the least centralized option and requires more work for the developer of each site, but it seems to be the only Microsoft-blessed way.
In conclusion, I'm pretty frustrated with .NET over this. In the grand scheme of things Master pages are just code, and I don't see any reason why they couldn't be easily centralized for use in multiple web applications. This seems to be a major loss compared to JSP/Java.
You can put some UI into the form of custom controls or server controls (if not in MVC) and then place them in the GAC thereby distributing them. All references to the controls in that assembly will be pulled from the latest version in the gac. You can also do things via the Machine.config which is controlled at the server level rather than the app level.