If you have a headless CMS combined with a SSG, what is the best way to push changes to your site? Do you listen for a change event and regenerate the whole site and redeploy each time? Or do you run the SSG on some timed interval?
I'm currently learning Gatsby(SSG) and Strapi(headless CMS), and I know Netlify offer services that combine SSG and a CMS for you. And Netlify does up to 3 builds per minute for free.
What is the best approach for pushing dynamic content to a SSG?
Both approaches would work. The first is known as webhooks and there is a planned plugin that you can vote for at https://strapi.io/vote
The latter is likely less efficient and can be achieved with a cron job, for now this is the option I think.
Related
I am working on a website of 3,000+ pages that is updated on a daily basis. It's already built on an open source CMS. However, we cannot simply continue to apply hot fixes on a regular basis. We need to replace the entire system and I anticipate the need to replace the entire system on a 1-2 year basis. We don't have the staff to work on a replacement system while the other is being worked on, as it results in duplicate effort. We also cannot have a "code freeze" while we work on the new site.
So, this amounts to changing the tire while driving. Or fixing the wings while flying. Or all sorts of analogies.
This brings me to a concept called "continuous migration." I read this article here: https://www.acquia.com/blog/dont-wait-migrate-drupal-continuous-migration
The writer's suggestion is to use a CDN like Fastly. The idea is that a CDN allows you to switch between a legacy system and a new system on a URL basis. This idea, in theory, sounds like a great idea that would work. This article claims that you can do this with Varnish but Fastly makes the job easier. I don't work much with Varnish, so I can't really verify its claims.
I also don't know if this is a good idea or if there are better alternatives. I looked at Fastly's pricing scheme, and I simply cannot translate what it means to a specific price point. I don't understand these cryptic cloud-service pricing plans, they don't make sense to me. I don't know what kind of bandwidth the website uses. Another agency manages the website's servers.
Can someone help me understand whether or not using an online CDN would be better over using something like Varnish? Is there free or cheaper solutions? Can someone tell me what this amounts to, approximately, on a monthly or annual basis? Any other, better ways to roll out a new website on a phased basis for a large website?
Thanks!
I think I do not have the exact answers to your question but may be my answer helps a little bit.
I don't think that the CDN gives you an advantage. It is that you have more than one system.
Changes to the code
In professional environments I'm used to have three different CMS installations. The fist is the development system, usually on my PC. That system is used to develop the extensions, fix bugs and so on supported by unit-tests. The code is committed to a revision control system (like SVN, CVS or Git). A continuous integration system checks the commits to the RCS. When feature is implemented (or some bugs are fixed) a named tag will be created. Then this tagged version is installed on a test-system where developers, customers and users can test the implementation. After a successful test exactly this tagged version will be installed on the production system.
A first sight this looks time consuming. But it isn't because most of the steps can be automated. And the biggest advantage is that the customer can test the change on a test system. And it is very unlikely that an error occurs only on your production system. (A precondition is that your systems are build on a similar/equal environment. )
Changes to the content
If your code changes the way your content is processed it is an advantage when your
CMS has strong workflow support. Than you can easily add a step to your workflow
which desides if the content is old and has to be migrated for the current document.
This way you have a continuous migration of the content.
HTH
Varnish is a cache rather than a CDN. It intercepts page requests and delivers a cached version if one exists.
A CDN will serve up contents (images, JS, other resources etc) from an off-server location, typically in the cloud.
The cloud-based solutions pricing is often very cryptic as it's quite complicated technology.
I would be careful with continuous migration. I've done both methods in the past (continuous and full migrations) and I have to say, continuous is a pain. It means double the admin time for everything, and assumes your requirements are the same at all points in time.
Unfortunately, I would say you're better with a proper rebuilt on a 1-2 year basis than a continuous migration, but obviously you know best about that.
I would suggest you maybe also consider a hybrid approach? Build yourself an export tool to keep all of your content in a transferrable state like CSV/XML/JSON so you can just import into a new system when ready. This means you can incorporate new build requests when you need them in a new system (what's the point in a new system if it does exactly the same as the old one) and you get to keep all your content. Plus you don't need to build and maintain two CMS' all the time.
We're building a new website design and instead of cutting over to it 100%, we'd like to ease into it so we can test as we go. The goal would be to have users that visit http://oursite.com to either get the "old" website or the new, and we could control the percentage of who gets the new site by 10%, 50%, etc.
I'm familiar with A/B tests for pages, but not an entire website domain. We're on a LAMP stack so maybe this can be done with Apache VHosts? We have 2 cloud servers running behind a cloud load balancer in production. The new site is entirely contained in an svn branch and the current production site runs out of the svn trunk.
Any recommendations on how I can pull this off?
Thanks you!
You absolutely can do this, and it's a great way to quickly identify things that make a big difference in improving conversion rates. It's dependent on a couple of things:
Your site has a common header. You'll be A/B testings CSS files, so this will only work if there's a single CSS call for the entire site (or section of the site).
You're only testing differences in site design. In this scenario all content, forms, calls to action, etc. would be identical between the versions. It is technically possible to run separate tests on other page elements concurrently. I don't recommend this as interpretation of results gets confusing.
The A/B testing platform that you choose supports showing the same version to a visitor throughout their visit. It would be pretty frustrating to see a site's theme change every time they hit another page. Most A/B testing platforms that I've used have an option for this.
Since you're testing substantial differences between versions, I also recommend that you calculate sample sizes before you begin. This will keep you from showing the losing version to too many people, and it will also give you confidence in the results (it's a mistake to let tests run until they reach statistical significance). There are a couple of online calculators that you can use (VisualWebsiteOptimizer, Evan Miller).
What is a good way to track deployments of our code base? I would like to be able to see when a version was deployed on a specific server, who released it, what issues were solved by it, etcetera.
Currently we have a deployment tool that generates an issue in our issue tracker with all this information. This makes it easy to link the release issue against related issues, but it also pollutes our issue database.
We also want to start with Continuous Integration internally, which would mean there would be a ton more release issues.
Are there better ways of tracking releases?
Our technology stack is PHP (Symfony2) using Phing as a build system, a custom, web-based deployment tool, Mantis for bugtracking and Bitbucket for repository hosting.
You can use something like Beanstalk or dploy.io to deploy your apps. It will give you an ability to manage deploy permissions, see a timeline of all deployments (who deployed what and when), trigger deployments with a single click and notify your team via email and integrations when something is deployed.
You can get an idea from this screenshot:
http://cl.ly/image/3C1v1w2C3K2v
P.S. I work at Wildbit, company that makes both products.
You should check out my company's product BuildMaster, it was designed to solve every problem you've listed.
At this time we do not yet have the first-class integration with Mantis, but it can be added pretty easily via extensibility in the same way as the other bug/issue trackers we integrate with. It could be either built by your team if you are interested in that or our team contingent on an Enterprise edition purchase.
We are getting lot of problems with dispatcher, As per CQ5 documentation dispatcher is cache and/or load balancing tool, so as per my analysis we can go with out dispatcher also,I am correct? I want to integrate Squid or varnish web cache with my apache, so want get shutdown the dispatcher, will it be a good option
Any views/help is appreciated.
Yes, it's perfectly possible to run a website without the Dispatcher in front. Your options would then seem to come down to:
No caching
Implementing a cache in front of the Publish instance (e.q. Squid/Varnish, as you mentioned; configuration required)
Integrate a caching solution in Java that you can apply to parts of your templates/components individually (development required)
Also, you'd need to check with Adobe what level of support they'd give you for any of the above solutions before undertaking them. If you like, you could post specific questions to SO around the problems you're facing with the Dispatcher and you may get some resolutions too.
I was told that you should use dispatcher servers for your publish instance, because it really helps the loading times. There also was a documentation with a table showing how much it affects the performance depending on the number of documents served.
To avoid caching problems, you can specify files, folders or file types which should never be cached. You can also specify caching behaviour in the source code of the pages. Also, making changes to content on your author instance triggers a flush on the dispatcher for the affected content, to make sure that no cached old version is beeing served.
Last but not least using an apache server also allows you to handle virtual hosts and rewrite rules easily.
Its a must.
If you are getting problems with dispatcher, this could be a sign that you are using the wrong platform for your development needs. Seeing as you are needing to revert to technologies that are not needed for AEM.
I'm working on improving a small intranet where files are currently edited directly on the server (connected via Samba). As you can imagine, I'd like to vastly improve this workflow with things like:
Version control
Validation of JavaScript and CSS (or SAAS) files
Minification of JavaScript and CSS (or SAAS) files
Transfer to live server (ideally to the server mounted, rather than SSH etc.)
Naturally I'd like this to be as automated as possible.
I've been looking around for a few hours on this subject and have come across similar questions and read about various tools (Ant, Capistrano, Maven, Phing, others…), but I'm struggling to get an overview of the whole process. Are there any good books or tutorials that step through a workflow, perhaps pointing out suitable tools along the way and showing basic examples?
There's a bunch of guides on our site about deployments. Take a look, maybe you will find the useful. Here's one about deployments best practices:
http://guides.beanstalkapp.com/deployments/best-practices.html
Here's one about configuring your first Capistrano recipe:
http://guides.beanstalkapp.com/deployments/deploy-with-capistrano.html
And this one is about managing Capistrano deployment with Beanstalk:
http://guides.beanstalkapp.com/deployments/managing-capistrano-deployments.html
Good luck!