I'm surprised I haven't found answers to this by Googling. I currently don't have any CDN and run my deploys through Ansible. I'm thinking of adding a CDN, but since cache is only invalidated on these intermittently, my understanding is that a deploy on my servers wouldn't change the static files served by my cdn for potentially hours. Of course, when I do a deploy, I'd like everything done as fast as possible, so if anything does go wrong (or right), I know about it immediately.
All of that said, how do I actually deploy to a CDN, telling it I'm serving some new set of static files now and that it should refresh these? Is there an Ansible module that does something like this, or an API for some CDN provider? I'd really like to avoid doing this manually on every deploy as this seems to imply for Cloudflare, for example.
Also, I'm currently using CloudFlare for other stuff, so sticking with them would be cool, but I'm willing to switch over to something else if it's better for my use case.
As an aside, this seems like a standard use case with a CDN, but I can't find much documentation or blog posts for how people regularly deploy to CDNs. Am I missing something?
Yeah, you could do a purge/invalidate, but that's not the best. Really, you want to use a tool that compiles* your CSS/SASS/whatever, images into sprites, and compiles your JS. Finally, the tool should understand static hosting, which means it uses a unique url for each publish. That way you don't have to purge, which is expensive for a CDN to do.
Thankfully, there are tools that handle this. I'm aware of Ruby's asset-pipeline, Grails's asset-pipeline, and Python's webassets.
Depending how you build your code and bake your stack, you might use Ansible to upload/deploy the static assets, though most of them have the ability to deploy locally or to s3.
* I'm using "compile", though it's really "minify/munge/compress" or "preprocess" or whatever.
Related
People often suggest CDNs for public library. The one I read today goes like this:
It's recommended that production applications utilize CDNs for common
libraries like AngularJS
https://learn.microsoft.com/en-us/aspnet/core/client-side/angular
Why it is recommended so?
One thing I can think of is, since the content comes from different domain, the browser specific limit for number of connections to a domain will not be a bottle-neck for loading scripts if multiple such libraries are being used. However, this can be solved by combining scripts.
Do you know any other benefits?
The answer you provided yourself is in-fact a good reason as to why you should use a CDN. Another reason which you overlooked and is dependent on how the CDN is structured is that, if the library gets updated, anyone using the CDN version will get the newest version with no hassle(obviously this wont work if you are referencing a file which has a version number directly i.e. jquery-1.3.2.js).
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.
I'm writing a small Mobile Web Application to get started.
So far so good, however I'm considering optimizing performance server-side.
After read about server compression and caching, I'd like to implement fingerprint of static resources. Basically, both W3 Mobile Web Application best practices and Google performance guide recommends it.
I'm using Grunt as the main tool to switch from development to production.
Found that Grunt got two plugins that can help me achieve that :
https://github.com/testdouble/grunt-asset-fingerprint
https://github.com/sapegin/grunt-fingerprint
However, I'm not sure how to update the html file to update link matching updated fingerprinted assets. Should i use some template variables ? I'm not a Grunt expert, use it only a few times for simple task so that might be the template system I have to dive in.
Anyway thanks by advance
If you're not too comfortable writing your own grunt tasks and would like to have asset fingerprinting as well as a ton of other features I suggest you look into Yeoman
http://yeoman.io
It'll set you up with a template for your webapp that just works. I've started using this quite a lot.
I really like drupal somehow. But what disturbs me most is that i can't figure out a clear way of deployment. Drupal stores a lot of stuff inside the database (views, cck, workflow, trigger etc) that needs to be updated.
I've seen some modules that could be used for this task (eg features) and I'm not sure if they are sufficient. Yet they are only for drupal6 and i currently have to work on a drupal5 site where updating is not yet an option.
Any ideas?
This is a weakness. Drupal doesn't have the developer tools built in that make development and deployment easy like Rails does (for example). One problem is Drupal isn't aware of it's environment natively. Secondly, there are too many different methods and modules that require special care. It can get very confusing. But things are getting better with drush and drush make.
I'm assuming here that you have a development environment on your local machine and a live or staging server you upload to.
The first thing you have to do is work out how to get your database fixture and your code to and from your server to your development environment very quickly. You need to make this proceedure as painless as possible so you can keep different versions of your site in sync without much effort. This will mean you will hopefully be able to manage less change every time you deploy. Hopefully...
Moving the database around isn't too hard. You could use phpMyadmin or mysqldump but the backup migrate module is my favorite tool.
To upload code from your local repository or site can be done in a few ways. If you use a version control system like git, you can commit on your local machine and check out again on the staging server. There are also special deployment tools like capistrano you should take a look at. (if you know this stuff already it may benefit others to read). If you're using FTP you should probably try something different.
If you're working with a site that is still in production, you can afford to make small incremental changes to your local site, then repeat on the live site and down load the new version of the database when your changes are in place. This does mean you double handle the database but can be a safe way of doing things. It keeps both your database closer to each other and minimises risk.
You can also export views backup to your server in either your code or importing them into your live site. There is a hack to get around deploying cck changes here: http://www.tinpixel.com/node/53 it works OK but cannot truly manage changes like rollbacks. (Respect to the guy who wrote that)
You can also use hook_updateN to capture changes and then run update.php to apply them. I worked on a d5 site with dozens of developers and this was the only way to keep things moving forward. This may be a good option if your site is live or if you need all database schema changes captured in a version control system (so you can roll back).
Also: Take a look at drush and drush make. These tools can be of great benefit. I can't remember how much support is for d5.
One final method of dealing with this is not to use cck or views (and use hook updates). But this is really only suitable for enterprise sites where you have big developer resources. This may seem like a strange suggestion but it can negate this whole problem completely.
Sorry I could not give you a clear answer. This is because one does not exist yet. You'll end up finding your own rhythm once you get into. Just keep backups of your database if you can roll back to them easy enough.
I have been looking into optimizing a website and specifically looking into CSS sprites, and serving static resources from a subdomain (static.mysite.com). Reference: Split Components Across Domains
We are using cassini (which comes with visual studio) for development and it does not support subdomains. My static resources are contained in the folder www.mysite.com/Contents/Static/..
This works for both cassini and IIS7.
If I should move these static assets to static.mysite.com, without making much changes in my codebase (references to js/css/images),what would be the most optimal way to do it ?
My concern is the fact that cassini does not support subdomains makes me think I should have 2 code bases ? Or I should somehow change my references to static assets in code base from mysite.com/contents/static to static.mysite.com during the build? How do you guys go about it ?
PS:On a side note, it would be nice if you guys can point me to good asp.net performance tuning articles (though google search helps)
This kind of becomes a question about your development environment and developer workflow.
Cassini is fine in your dev-env so long you eventually system/user-acceptance test against the target webserver that is used in the production environment.
If you'd like to stick with Cassini, I'd go for a separate webserver, such as lighthttpd, for serving static content during development. Once you have it serving from the correct document root, you can pretty much forget about it.
Alternatively, if you are open to running IIS then you could quite easily shift off Cassini.
As for static content references in your code, the general approach is to build up the absolute URL for each static resource using a variable from your masterpage (or config). I wouldn't recommend any string substitution at build/deploy time.
My first question is... why are you using Cassini at all? Why not develop against the server you're actually using?
Two code bases is a horrible idea...
Unless you're actually serving resources from two different machines, you are not going to see a performance change between www.mysite.com/contents/static and static.mysite.com. Just not going to happen. I've generally found Yahoo's perf advice to be pretty good... but this one is just silly.
What you probably want is a completely different domain name altogether. For example, Google uses "gstatic.com" and Facebook uses "fbcdn.net" to serve static content. Cookies between subdomains may be shared and unnecessarily sent/received to/from the subdomain serving static content thereby adding overhead. You do take a DNS lookup hit at the browser level but it's worth the reduced overhead from serving static content from a cookie-less domain.