You no longer need dynamic Web pages--edit-publish-dev Detach

? Although there is no special incentive to build a new CMS, I would like to write an article on how to do it-the editor-publisher-development separation model works. MicroServices are a trend for complex applications, and the edit-publish-Develop separation model is another trend. In the previous article, "Repractise Architecture Chapter One: the restructuring and evolution of CMS", we talked about the editorial-release-development separation model.

System architecture

As mentioned earlier, Carrot uses the following scheme to build a CMS for their static content.

The content in this scenario is to use contentful to publish their content. In our ThoughtWorks's official website, GitHub was used to manage the content. So if we were to write a GitHub-based CMS, then the architecture became:

Perhaps you have used static blogs like hexo/jekyll/octopress, and their principles are similar. We have a code base for generating static pages, and then these static pages will be push onto GitHub pages.

From the point of view of our design system, we have three code libraries on GitHub:

1. Content. Used to store the JSON files generated by the editor so that we can get these resources and build the spa with backbone/angular/react these front-end frameworks.
2. Code. Developers are here to store their code, such as themes, static file generators, resource files, and so on.
3. Builder. Here it is a script file that runs on Travis Ci, used for clone code, and executes the script in code.

As well as some additional services when and only when you have some additional functional requirements.

1. Extend Service. When we need to search for services, we need some of these services. If I'm thinking of using Python's whoosh to do this, I'm planning to use the Flask framework, but only in the plan-because there's no proper middleware.
2. Editor. This step is more important than the previous knowledge, which is why the resulting format is JSON rather than markdown. For non-programmers, mastering markdown is not an easy task. So, one of the scenarios to consider is to use Electron + node. js to generate the API and finally upload it via GitHub API V3.

So, how this process is carried out.

User Scenarios

The pipeline of the entire process is as follows:

1. Edit the content using their editor and click Publish, and the content will be uploaded to the repo via the GitHub API.
2. At this point a webhooks is required to monitor the changes to the content code base and run the Travis CI of the builder code base.
3. The builder script first sets up some basic git configuration. Then clone the content and code codes, then run the build command to generate the new content.
4. Then the builder commits the content and push the content.

This is also dependent on webhook-a suitable solution has not been thought of. Below, we do some of the contents of the disassembly, content inside because it is JSON is not much explained.

Builder: Build Tools

Between GitHub and Travis, you can do an automated deployment tool. It is believed that a lot of people have been playing this thing on GitHub-first generate tokens on GitHub and then encrypt them with Travis:

travis encrypt-file ssh_key --add

The encrypted key is saved to the .travis.yml file, and then you can push your code onto GitHub on Travis Ci.

Next, you need to create a deploy script and after_success execute it:

after_success:  - test $TRAVIS_PULL_REQUEST == "false" && test $TRAVIS_BRANCH == "master" && bash deploy.sh

In this script, all you need to do is clone content and code, and execute the build script in code, generate the new content, and commit the code.

#!/bin/bashSet-O errexit-o nounsetrev=$ (git rev-parse--short HEAD)CDStage/git initgit config User.Name"Robot"git config user.email"[email protected]"Git remote add upstream"https://$GH _token@github. Com/phodal-archive/echeveria-deploy.git"git fetch upstreamgit reset upstream/gh-pagesgit clone Https://github.com/phodal-archive/echeveria-deploy codegit Clone https://github.com/phodal-archive/echeveria-content ContentpwdCp -AContent/contents code/contentCDCODENPM installnpm Install Grunt-cli-ggrunt mv dest/*. /CD.. /RM-RF CODERM-RF Contenttouch.if[ !- FCNAME]; Then    Echo "Deploy.baimizhou.net"> CNAMEfiGit add-a. Git commit-m"rebuild pages at ${rev}"git push-q upstream head:gh-pages

That's what this builder does--one of the main tasks is that what grunt it does is:

grunt.registerTask(‘default‘, [‘clean‘‘assemble‘‘copy‘]);

Code: Static page generation

Assemble is a static web page generation system that is implemented using Node.js,grunt.js,gulp,yeoman and so on. There are many such generators, such as Zurb Foundation, Zurb Ink, less.js/lesscss.org, topcoat, Web Experience Toolkit and other organizations that use this tool to generate. This tool seems to have last release more than a year ago and is now starting 0.6. Although, this is not important, but I still say by the way.

All we have to do is Gruntfile.js write the corresponding generated code in our.

Assemble: {options: {flatten:true, partials: [' Templates/includes/*.hbs '], Layoutdir:' templates/layouts ', Data:' Content/blogs.json ', Layout:' Default.hbs '}, site: {files: {' dest/': [' Templates/*.hbs ']}}, Blogs: {options: {flatten:true, Layoutdir:' templates/layouts ', Data:' Content/*.json ', partials: [' Templates/includes/*.hbs '], pages:pages}, files: [{dest:'./dest/blog/'Src:'!* '}        ]      }    }

The site in the configuration is used to generate page-related content, and the blogs can be stored in the blog directory based on the file name of the JSON file.

The resulting catalog results are as follows:

 .├── about.html├── blog│   ├── blog-posts.html│   └── blogs.html├── blog.html├── css│   ├── images│   │   └── banner.jpg│   └── style.css├── index.html└── js    ├── jquery.min.js    └── script.js730 files

The static file content here is the final content we want to publish.

The other thing to do is:

grunt.registerTask(‘dev‘, [‘default‘‘connect:server‘‘watch:site‘]);

For the development phase such code is enough, this and you use Webpack + React does not seem much difference.

Edit-Release-development separation

In this case, the editor can complete the work without relying on the website-unscripted and less an excuse. This time the site error is too small-you do not need a cache server, HTTP server, because there is no dynamically generated content, you do not need to daemon. These are static files, and you can put them in any place that can provide static file hosting--cloudfront, S3, and so on. Or you can trust your own server, Nginx is the second best in the world (the first has not appeared) of the static file server.

Developers are only going to modify some of the site's content when they need it.

So, you may be worried about what to do if there is something wrong with the modification at this time.

1. Using this pattern means that you need to have tests to cover these build tools and build tools.
2. Compared to their own code, others are more reliable CMS?

It is important to note that if your last build was successful, the files you generated are normal, then you just need to roll back the development-related code. The old code can still work very well.

Second, because of the static files generated, the cost of the error is relatively low.

Finally, put the previous static file back on.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

You no longer need dynamic Web pages--edit-publish-dev Detach