iilab / contentascode

Content as Code
http://iilab.github.io/contentascode
GNU General Public License v3.0
34 stars 7 forks source link

Design DX for contentascode adoption #15

Open jmatsushita opened 8 years ago

jmatsushita commented 8 years ago

Part of #7

My thoughts on this would be to focus on allowing user to start from a project scaffold:

We could create repos (contentascode-blog, contentascode-wiki, contentascode-website, contentascode-doc) that are ready to clone with some sensible defaults.

The default pipelines would have a travis.yml that push to a gh-pages branch.

We could also look into Grunt-init or Yeoman Project Scaffolding tools to allow configuration of various options such as:

We also need to think about migration and various options to use integrations to facilitate a progressive transition process.

Reference Implementation Matrix

Name Description Repo Editor Generator Build Hosting Services
scaffold-github-pages Fork and play. Github Prose Jekyll Github Pages Github
scaffold-github-jekyll-travis With Jekyll and Travis CI Github Prose Jekyll Travis Github
scaffold-github-metalsmith-travis With Metalsmith and Travis CI Github Prose Metalsmith Travis Github
scaffold-jekyll-jenkins Open souce stack Gitlab Hosted Prose Jekyll Jenkins Self-Hosted
scaffold-metalsmith-gitlabci Open souce stack with metalsmith Gitlab Hosted Prose Jekyll Gitlab CI Self-Hosted
infra-heroku Push to deploy micro-service infra Gitlab Hosted Prose Jekyll Jenkins Heroku Single container
infra-docker Docker single server micro-service infra Multi-container
infra-ansible Distributed micro-service infra Multi-server
jmatsushita commented 8 years ago

This should also grow to include criteria (and later test tools) to determine if an implementation is following the content as code principles.

jmatsushita commented 8 years ago

This repo is currently an implementation of the stack-github-pages approach. Not sure it can be made completely fork and play as it might always require to activate Pages on the github repo.

Moving to the stack-github-jekyll-travis approach will add the following features:

From a DX standpoint, moving to this stack should be as simple as changing branches and merging (and configuring travis). Will open a new issue to track this.