What is your front-end development workflow?

Question

Regular Expressions

Let me explain - for me now it all comes down to
1) I uploaded the basis of the site to the hosting and I am already writing it there; (I do both design and layout myself)
2) any changes to the code are made through the filezilla + sublime bundle (portable with relative paths and synchronization in Dropbox, several working machines and it is not always clear which one I will work on).
I really want to switch to sass + compass, but I don’t understand - do I need to compile and upload to the site after each edit? Then you need version control so that it doesn’t break everything, and these 2 features have already greatly complicated the workflow (I still don’t refuse those goodies that collectors give me, etc.).
Is there some kind of IDE that will interpret css from an ftp server into sass on the fly, and after editing, compile it back into css and then upload it to the server?)

Answer 1

The layout is as follows:
1. Take a docker container with a configured environment for development.
This is convenient if suddenly the developer becomes more than one, the system crashes, you change the workplace. Set it up and forget it once)
docker starts:
- web server (you can use nginx, you can do it inside gulp, it all depends on the task)
- livereload server, through gulp ( press f5 every 3 seconds - it hurts
- gulp watchers ( manually compile all sorts of crap , it's boring to run tests)
2. Run vim (or any of your favorite editors)
3. write, [email protected]#b, code:
- less, sass, etc. for me is much more convenient than pure css, you write less code, you get more code.
- don't write bare html, use any templating engine you like, I use twig, but simple {{mustache }} will do
4. use git. And use it often.
- install gitlab for friendly projects
- use gitworkflow, well, or make at least 2 branches: for example, master and prodaction (more on that later)
5. CI
- while working, you still make a lot of mistakes. Syntax checks, validation against standards, tests - they all help you not to screw up.
- if you do it yourself, you will lose a lot of time just to run and check all your work. ci server will help you remove this routine from your life.
6. Crossbrowsing
- use the browserstack (or similar) to view the results of your work
- well, if you find an error, take a real browser (or in a virtual machine) debug
- getting screenshots easily connects to ci
- and also works with local servers out of the box
7. Feedback with the customer
- for the master branch (and indeed for any other branch) in git, you can easily raise a site with the latest code updates with the help of a ci server + docker
- do it at your place and you can not be afraid that the customer will be able to pick up your work and forget pay
8. Deploy
- I just use gitlab-ci-worker on the required server and get everything the same as p.7
- but for this I use only the prodaction branch, in which I post stable changes when ready
- just hosting - anything (shell, ansilbe + ssh ) via ci server
- And don't forget that for prodaction you need to compress all assets (yes , yes, I'm talking about ci)
9 Be happy
Throw out the routine, and do what you like. Write the code))
PS
This is not an instruction on how to work, not an advertisement for tools. This is the description of my workflow.

Answer 2

Learn GIT, automate your routine via gulp/webpack/etc, read a book about continuous improvement (lean) and keep improving your workflow so that there are no distractions at all.

Answer 3

1. the system is locally deployed in the Vagrant virtual machine, almost the same as the demo-server and prod-server.
2. all code is sent to bitbacket to the git repository in the dev branch
3. bamboo periodically checks the state of the dev branch (by hook + timeout) and runs unit tests 15 minutes after the last commit
4. if the tests pass, merge the dev branch -> to the demo branch. There are no conflicts.
5. deployhq determines from the hook that the demo branch has changed and starts the automatic update of the demo server. Before updating (* see below), the database is dumped, the user interface is closed, cron tasks and queues are extinguished (** see below). After the update, the database is dumped, the interface is opened, cron tasks and queues are restored, and the cache is restarted.
6. speed metrics are collected from the demo server and selenium tests are done
7. when the release, manually merge dev -> prod. There are no conflicts.
8. deployhq determines by hook that the prod branch has changed and starts automatic updating of the prod server. Before updating, the database is dumped, the user interface is closed, cron tasks and queues are extinguished. After the update, the database is dumped, the interface is opened, cron tasks and queues are restored, and the cache is restarted.
9. if hotfixes, then you restore your database from the last dump, take the code from prod, fix it, commit it to prod, then merge prod -> demo -> dev
* update - what's that?
Updating source codes (PHP, Python, JS, SCSS), compiling and compressing CSS, building and compressing JS, updating dependencies, installing updates to the database.
** why close the interface, put out cron and queues?
There are a lot of things in the project that are not stored in the repository, namely: CSS built from SCSS, a modular application in AngularJS with a bunch of dependencies, git submodules, packages for PHP (composer) - they are rebuilt on bamboo, on demo, on prod. It takes time. To avoid failures, turn off everything except the assembly itself. On developer machines, all dependencies are updated as needed, and on CSS and JS, gulp keeps track.
Setting up this entire kitchen took 2 months. For other projects - a week maximum.
Links: Bitbucket (git) ,Vagrant (develop) , Bamboo (continuous integration) , Deployhq (continuous deployment) .
Well, a little advertising from the sponsor ;)
Icons8 15 000+ free flat style icons Our technology stack on stackshare.io

Answer 4

You can use a build on gulp / webpack with livereload / hotreload, which will already have a test local server. It's much easier and more efficient.

Answer 5

I have this now:
grunt scss on it and a mini server with livereload. 2 folders src and production.
I do all the actions in the src folder, and grunt collects everything in the production folder, which I follow with liveload.