Our team works with many websites that use Sass/Compass to compile and minify CSS.
Working with this current setup is great when you have all of the files stored locally and your development workflow is setup. However, when you push the site live and a few days down the road are asked to make a change, it's not a huge deal, the local files are there and you just have to compile and push up again.
But if you are working with a site someone else pushed live and now need to make a small change requested by the client, you have to pull all the files down, setup the development workflow with Sass/Compass and make the changes then compile and push up again.
This process is extremely time consuming when you have to make 20 small changes in a day.
It would be ideal to only have to:
pull one file down,
make the change,
push it live and somehow the server complies it.
I haven't been able to find a solution and I also am not an experienced server side developer, so I'm asking you guys if you have a better development workflow setup that allows for all of this to happen and yet, makes it easy to make small changes in the future.
Little information, but I think it would have to do to use partial file css several are not generated to compile.
Related
I was wondering how you would go about managing .SCSS files when a project has launched. For example I manage a number of websites & use the power of SCSS while building them.
However once a project has launched if I'm required to make a small edit currently I just ftp to the minified .css file and tag the extra few lines to the bottom... Bad I know!
Then when it comes to a larger change to an existing project the .scss files are rendered unless as the .css is ahead of the .scss therefore re-compiling the .scss will overwrite smaller chnages that have taken place.
The only way I could think to go about this would be to create an _updates.scss file and tagging all the small updates into this file. However this will take much longer than the current ftp'd changes.
What would you recommend?
I'd suggest still using Sass, it seems a waste not to after you've used it this far too for building the majority of the styling. It sounds like less of a Sass vs CSS issue (once on live) but more of a poor workflow.
If it seems slow editing once it's on live, consider an improved workflow - Use Git for version control (or similar), and possibly setup deployments, along with Grunt/Gulp to make Sass watches and recompiling a little easier to once it's all setup (sometimes it's a good idea to extend the functionality of these task runners to lint and minify code). Then you can stay up to date (using Git), make required changes and then you can deploy the compiled stylesheets. I use this simple workflow for a lot of projects, big and small and it's very efficient. Keeping an efficient level of maintainability for codebases is essential i think, and the first place you can improve this is your workflow. (see above)
I've been tasked with starting a complete UI redesign for an App that is already coded in Ruby on Rails. Honestly, I'm not sure where to start. Would it be easier to start from scratch or go through and modify the existing code?
The issue I see with modifying the existing code is that there are legacy artifacts that could conflict with the new UI code (CSS classes, ids, styling, etc.) which would make the redesign project probably take longer.
The issue I see with starting from scratch is that I'd literally start from scratch. There are existing migrations that I'd have to re-run by first clearing out the DB, which I can't do on a production server. Re-run all of the install scripts (like Devise, Rubber, etc.).
Has anyone gone through this before? Any recommended things to do?
Can I just hook into the existing DB and not have to run any migrations (since I can't do that in production)? Surely ppl that do this have some trick to getting back up and running smoothly.
Since you mentioned UI redesign, I wonder how that affects the DB. However, generally my approach to such would be to first do a HTML/CSS design to show how the new UI would look, both with and without data, then break those HTML down into components or partials then, I'd start replacing old components with the new components. I'd probably start from the root route and build up.
You shouldn't really need to clear out DBs or anything of sorts, I prefer to use SQLite for local development. If you'd like to test with data, you should probably find a way of seeding some of the data or copying data from the main application to your localDB. I'd never advice that you use your production DB with your development environment.
Just thought to share my 2 cents.
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 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.
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.