Merge branch 'staging' into 'master'

Staging environment

See merge request !13

.gitlab-ci.yml

@@ -2,25 +2,44 @@
 # Full project: https://gitlab.com/pages/middleman
 image: ruby:2.3
+stages:
+  - build
+  - deploy
+
 cache:
   paths:
   - vendor
-test:
+  - vendor-s3
+build:
+  stage: build
   script:
   - apt-get update -yqqq
   - apt-get install -y nodejs
   - bundle install --path vendor
   - bundle exec middleman build --verbose
-  except:
-    - master
+  artifacts:
+    paths:
+      - build
+
+# http://aws-website-staginginemat-ugfk6.s3-website-us-east-1.amazonaws.com
+s3:
+  image: registry.gitlab.com/inem/railshurts
+  variables:
+    BUNDLE_GEMFILE: Gemfile-s3
+  stage: deploy
+  environment: staging
+  script:
+    - bundle install --path vendor-s3
+    - bundle exec s3_website push
+  only:
+  - staging
 pages:
+  image: alpine
+  stage: deploy
+  environment: production
   script:
-  - apt-get update -yqqq
-  - apt-get install -y nodejs
-  - bundle install --path vendor
-  - bundle exec middleman build --verbose
   - mkdir -p public && cp -r build/* public/
   artifacts:
     paths:

Gemfile-s3

+# If you do not have OpenSSL installed, update
+# the following line to use "http://" instead
+source 'https://rubygems.org'
+
+gem "s3_website"
\ No newline at end of file

Gemfile.lock

@@ -18,6 +18,7 @@ GEM
       coffee-script-source
       execjs
     coffee-script-source (1.10.0)
+    colored (1.2)
     compass (1.0.3)
       chunky_png (~> 1.2)
       compass-core (~> 1.0.2)
@@ -30,6 +31,10 @@ GEM
       sass (>= 3.3.0, < 3.5)
     compass-import-once (1.0.5)
       sass (>= 3.2, < 3.5)
+    configure-s3-website (1.7.1)
+      deep_merge (= 1.0.0)
+    deep_merge (1.0.0)
+    dotenv (1.0.2)
     em-websocket (0.5.1)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
@@ -104,6 +109,11 @@ GEM
     rb-fsevent (0.9.7)
     rb-inotify (0.9.7)
       ffi (>= 0.5.0)
+    s3_website (2.11.0)
+      colored (= 1.2)
+      configure-s3-website (= 1.7.1)
+      dotenv (~> 1.0)
+      thor (~> 0.18)
     sass (3.4.22)
     sprockets (2.12.4)
       hike (~> 1.2)
@@ -133,6 +143,7 @@ PLATFORMS
 DEPENDENCIES
   middleman (~> 3.4.0)
   middleman-livereload (~> 3.1.0)
+  s3_website
 BUNDLED WITH
    1.12.3

s3_website.yml

+s3_id: <%= ENV['S3_ID'] %>
+s3_secret: <%= ENV['S3_SECRET'] %>
+s3_bucket: aws-website-staginginemat-ugfk6
+
+# Below are examples of all the available configurations.
+# See README for more detailed info on each of them.
+
+site: build
+
+index_document: index.html
+error_document: error.html
+
+# max_age:
+#   "assets/*": 6000
+#   "*": 300
+
+# gzip:
+#   - .html
+#   - .css
+#   - .md
+# gzip_zopfli: true
+
+# See http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region for valid endpoints
+# s3_endpoint: ap-northeast-1
+
+# ignore_on_server: that_folder_of_stuff_i_dont_keep_locally
+
+# exclude_from_upload:
+#   - those_folders_of_stuff
+#   - i_wouldnt_want_to_upload
+
+# s3_reduced_redundancy: true
+
+# cloudfront_distribution_id: your-dist-id
+
+# cloudfront_distribution_config:
+#   default_cache_behavior:
+#     min_TTL: <%= 60 * 60 * 24 %>
+#   aliases:
+#     quantity: 1
+#     items:
+#       CNAME: your.website.com
+
+# cloudfront_invalidate_root: true
+
+# concurrency_level: 5
+
+# redirects:
+
+
+# routing_rules:
+#   - condition:
+#       key_prefix_equals: blog/some_path
+#     redirect:
+#       host_name: blog.example.com
+#       replace_key_prefix_with: some_new_path/
+#       http_redirect_code: 301

source/shorten-cycle.html.haml

@@ -10,15 +10,12 @@
   .col-md-6.col-xs-7
     =img("/images/shorten2.png")
-%p Use these measurements to reduce cycle time. Actually it is a natural thing to do, when you have numbers before the eyes.
+%p Use these measurements to reduce cycle time. It is a natural thing to do when you have numbers before the eyes.
 %h3 Start working on Minimum Viable Changes
 %p
-  First thing to consider is to start working on smaller pieces of functionality. Instead of minimum viable products or minimum viable features, start thinking in terms of Minimum Viable Changes.
-
-
--# %div.aside The idea of MVC echoes with Kaizen - Japanese term for continuous improvement.
+  The first thing to consider is to start working on smaller pieces of functionality. Instead of minimum viable products or minimum viable features, start thinking in terms of Minimum Viable Changes.
 .row
   .col-md-2.col-xs-1
@@ -28,12 +25,13 @@
   .col-md-2.col-xs-1
      
-%p
-  Shipping smaller has following benefits:
-%row
+%h3
+  Benefits of shipping smaller
+
+.row
   .col-md-6.col-xs-6
-    %h4 for business:
+    for business:
     %ul
       %li More in line with expectations and needs of stakeholders
       %li Easier to coordinate and to reason about
@@ -42,7 +40,7 @@
       %li Higher predictability
   .col-md-6.col-xs-6
-    %h4 for developers:
+    for developers:
     %ul
       %li Prevents overshooting needs and gold plating
       %li Higher code review quality
@@ -54,21 +52,23 @@
 %h3 Include Gatekeepers into conversation
 %p
-  Think about Gatekeepers who had to approve something before you can ship it: Security review, Operations department, UX check, Translation department, QA testing.<br/>
-  We often exclude them from the equation, assuming there’s nothing we can do about it.
-%p
-  But we usually can. Give early access to your code to security department, make UX guy a part of the team, automate testing and operations together, etc.
+  Think about Gatekeepers who had to approve something before you can ship it: Security review, Operations department, UX check, Translation department, QA testing.
+.row
+  .col-md-3.col-xs-1
+    &nbsp;
+  .col-md-6.col-xs-6
+    =img("gatekeepers.png")
+  .col-md-3.col-xs-1
+    &nbsp;
 %p
-  PICTURE about gatekeepers
-%p
-  Here’s list of changes to think about:
+  We often exclude them from the equation, assuming there’s nothing we can do about it. But we usually can. Give early access to your code to security department, make UX guy a part of the team, automate testing and operations, etc.
+
+%h3 List of changes to think about
 %ul
-  %li Deploy infrequently → Deploy frequently (if it hurts do it more often)
+  %li Deploy infrequently → Deploy frequently (if it hurts, do it more often)
   %li Multiple changes → Single changes (able to link problems to changes quickly)
   %li Deploy in weekend → Deploy on peak times (prioritize finding problems quickly)
   %li Human integration testing → Automated integration testing (test everything)
-
-