Written by Torstein Krause Johansen updated: Tuesday August 16 2016 12:29
We had a number of requirements and wishes when we set out creating blogs.escenic.com a couple of them were:
We wanted to use the latest versions of all our products, including Escenic Content Engine and CUE the new web interface to replace both Escenic Content Studio in version 6.
Changes in the source code should be rolled out to the server as quickly and as hassle free as possible.
It should have a great developer experience (DX), writing a blog post should be fun for developers.
In the upcoming version 6 of Escenic Content Engine, the most important actors are:
When a user browses a page on the website, the call flow is as follows: ⛹ ➡ Waiter ➡ Cook ➡ ECE
We're using the upcoming version 6 of Escenic Content Engine, what
is the develop branch in our internal Git repository and we're using
the all new decouple presentation layer instead of the classic
Java/JSP/Struts. Likewise, the front end is the CUE web interface
pulled from the develop branch of that Git repository.
To get continuous deployment (CD), we've set up Jenkins jobs to sync code changes to the Cook and Waiter repositories are automatically with the test and production machines.
We've set up the following rules:
When something is merged to the develop branch, it's automatically
synced and deployed to
test.blogs.escenic.com
When code is merged to the master branch, the code is
automatically synced to
blogs.escenic.com, but it's not
deployed. For this one mouse click in Jenkins is needed.
We imagine most of the blog posts will be written by technical staff here at Escenic: R&D, Professional Services, The Cloud operations and QA.
For this reason, we implemented support for Markdown in the Waiter so that posts can be written in Markdown and rendered as HTML when when the blog posts are browsed.
In the screenshot above, I'm editing this blog post in Emacs, launched from the web browser while working on the blog in CUE. With CUE and Markdown we have all the choice in the world: bloggers can use whatever editor or tool they like for authoring the posts!
Another thing we've added support for on this blog, is nice code fragments. Code snippets are an important part of any technical blog and we've therefore used highlight.js which gives us rich syntax highlighting with many themes.