3 ms·
The same as with any software: a deployment pipeline. Depending on your needs, a staging version can be built and hosted. To be promoted to production once chi
by berkes 5y ago
The same as with any software: a deployment pipeline.
Depending on your needs, a staging version can be built and hosted. To be promoted to production once chief editor Acks. Or multiple such versions.
You can have multiple stages. Or just one, with a preview on localhost. You can have testsuites crawling a build. Or just a manual quick glance.
This problem is not hard. It is, in fact, much simpler to solve with static sites.
- seanwilson 5y agoLike say you want to update the heading text and background image for a landing page header and check it looks good on desktop and mobile. Does it line wrap nicely? Maybe bolding some words would look good? Is the text still readable when it overlaps the image? I want to be able to preview and tweak this kind of thing in seconds. What would you use for this? I wouldn't want to wait a minute for Netlify to build and deploy to staging each time for example.
- berkes 5y agoI use jekyll --preview for that. It seems you want to optimize your frontend-work. Tweaking a live setup that goes `client-> CMS -> Database. [switch-tab] [F5-refresh] -> client -> CMS -> Database -> client` is quite certainly not the direction you want to go. Instead, most frontend-development optimizes with things like that jekyll --preview: some devserver that autoreload (and autorefreshes!) your website on change. I now ask you: if you are happy about the changes: How do you save it? How do you reproduce it onto those other two websites? Or, if you were carefull and did the work on test/acceptance/staging, how to reproduce it on production? How do you communicate to your colleagues what has changed? How do you communicate to your future self what you changed? This stuff commonly lives in code, which is version controlled. Having it in a database is suboptimal, for this reason too.