docs: Revise automated deployment tutorial

Update tutorial to reflect changes to Wercker website.

docs/content/tutorials/automated-deployments.md

@@ -2,7 +2,7 @@
 authors:
 - Arjen Schwarz
 - Samuel Debruyn
-lastmod: 2015-11-01
+lastmod: 2017-2-26
 date: 2015-01-12
 linktitle: Automated deployments
 toc: true
@@ -137,7 +137,7 @@ After you are registered, you will need to link your GitHub and/or Bitbucket acc
 
 ## Add your project
 
-Now that we've got all the preliminaries out of the way, it's time to set up our application. For this we click on the **+ Create** button next to Applications, and then we'll choose to use GitHub as our provider.
+Now that we've got all the preliminaries out of the way, it's time to set up our application. For this we click on the **+ Create** button next to Applications. Create a new application, and choose to use GitHub.
 
 ![][6]
 
@@ -151,71 +151,65 @@ Clicking this will make Wercker show you all the repositories you have on GitHub
 
 [7]: /img/tutorials/automated-deployments/wercker-select-repository.png
 
-## Select the repository owner
+## Configure access
 
-In the next step, Wercker asks you to select the repository owner. Just select your own GitHub account and continue.
+As Wercker doesn't access to check out your private projects by default, it will ask you what you want to do. When your project is public, as needs to be the case if you wish to use GitHub Pages, the top choice is recommended. When you use this it will simply check out the code in the same way anybody visiting the project on GitHub can do.
 
 ![][8]
 
-[8]: /img/tutorials/automated-deployments/wercker-select-owner.png
+[8]: /img/tutorials/automated-deployments/wercker-access.png
 
-## Configure access
+## Public or not
 
-This step can be slightly tricky. As Wercker doesn't access to check out your private projects by default it will ask you what you want to do. When your project is public, as needs to be the case if you wish to use GitHub Pages, the top choice is recommended. When you use this it will simply check out the code in the same way anybody visiting the project on GitHub can do.
+This is a personal choice; you can make an app public so that everyone can see more details about it. This doesn't give you any real benefits either way in general, although as part of the tutorial I have of course made this app public so you can see it in action [yourself](https://app.wercker.com/#applications/5586dcbdaf7de9c51b02b0d5).
 
 ![][9]
 
-[9]: /img/tutorials/automated-deployments/wercker-access.png
+[9]: /img/tutorials/automated-deployments/public-or-not.png
 
 ## Wercker.yml
 
-Wercker will now attempt to create an initial *wercker.yml* file for you. Or rather, it will create the code you can copy into it yourself. Because there is nothing special about our project according to Wercker, we will simply get the `debian` box. So what we do now is create a *wercker.yml* file in the root of our project that contains the provided configuration, and after we finish setting up the app we will expand this file to make it actually do something.
+Choose Default for your programming language. Wercker will now attempt to create an initial *wercker.yml* file for you. Or rather, it will create the code you can copy into it yourself. Because there is nothing special about our project according to Wercker, we will simply get the `debian` box. So what we do now is create a *wercker.yml* file in the local root of our project that contains the provided configuration, and after we finish setting up the app we will expand this file to make it actually do something.
 
 ![][10]
 
 [10]: /img/tutorials/automated-deployments/werckeryml.png
 
-## Public or not
+## And we've got an app
 
-This is a personal choice, you can make an app public so that everyone can see more details about it. This doesn't give you any real benefits either way in general, although as part of the tutorial I have of course made this app public so you can see it in action [yourself](https://app.wercker.com/#applications/5586dcbdaf7de9c51b02b0d5).
+The application is added now, and Wercker will be offering you the chance to trigger a build. As we haven't pushed up the **wercker.yml** file however, we will politely decline this option. Wercker has automatically added a build pipeline to your application.
+
+## Adding build step
+
+And now we're going to add the build step to the build pipeline. First, we go to the "Registry" action in the top menu and then search for "hugo build". Find the **Hugo-Build** task by Arjen and select it.
 
 ![][11]
 
-[11]: /img/tutorials/automated-deployments/public-or-not.png
-
-## And we've got an app
-
-The application is added now, and Wercker will be offering you the chance to trigger a build. As we haven't pushed up the **wercker.yml** file however, we will politely decline this option.
-
-![][12]
-
-[12]: /img/tutorials/automated-deployments/and-we-ve-got-an-app.png
-
-## Adding steps
-
-And now we're going to add the steps themselves. First, we go to the "Registry" action in the top menu and then search for "hugo build". The first result is the **Hugo-Build** task, which we select.
-
-![][13]
-
-[13]: /img/tutorials/automated-deployments/wercker-search.png
+[11]: /img/tutorials/automated-deployments/wercker-search.png
 
 ## Using Hugo-Build
 
-Inside the details of this step you will see how to use it. At the top is a summary for the very basic usage, but when scrolling down you go through the README of the step which will usually contain more details about the advanced options available and a full example of using the step.
+Inside the details of this step you will see how to use it. At the top is a summary for very basic usage, but when scrolling down you go through the README of the step which will usually contain more details about the advanced options available and a full example of using the step.
 
-We're not going to use any of the advanced features in this tutorial, so we'll return to our project and add the details we need to our wercker.yml file so that it looks like the below. Wercker also has a [page](http://devcenter.wercker.com/articles/werckeryml/validate.html) for validating wercker.yml files, and it's usually a good idea to do so before committing changes as minor typos might cause it to fail.
+We're not going to use any of the advanced features in this tutorial, so we'll return to our project and add the details we need to our wercker.yml file so that it looks like below: 
 
 ```yaml
 box: debian
 build:
   steps:
+    - install-packages:
+        packages: git
+    - script:
+        name: download theme
+        code: |
+            $(git clone https://github.com/spf13/herring-cove ./themes/herring-cove)
     - arjen/hugo-build:
         version: "0.14"
         theme: herring-cove
         flags: --buildDrafts=true
 ```
 
-This concludes the first step, so we'll test that it all works as it should by pushing up our wercker.yml file and seeing the magic at work.
+As you can see, we have two steps in the build pipeline. The first step downloads the theme, and the second step runs arjen's hugo-build step. To use a different theme, you can replace the link to the herring-cove source with another theme's repository - just make sure the name of the folder you download the theme to (./themes/your-theme-name) matches the theme name you tell arjen/hugo-build to use (theme: your-theme-name). Now we'll test that it all works as it should by pushing up our wercker.yml file to Github and seeing the magic at work.
 
 ```bash
 git commit -a -m "Add wercker.yml"
@@ -224,13 +218,25 @@ git push origin master
 
 Once completed a nice tick should have appeared in front of your first build, and if you want you can look at the details by clicking on it. However, we're not done yet as we still need to deploy it to GitHub Pages.
 
-![][14]
+![][12]
 
-[14]: /img/tutorials/automated-deployments/using-hugo-build.png
+[12]: /img/tutorials/automated-deployments/using-hugo-build.png
 
-## Adding a GitHub Pages step
+## Adding a deploy pipeline
 
-In order to deploy to GitHub Pages we need to add a deploy step. Once again searching through the Steps repository we find that the most popular step is the **lukevevier/gh-pages** step so we add the configuration for that to our wercker.yml file. Additionally we need to ensure that the box we run on has git and ssh installed. We can do this using the **install-packages** command, which then turns the wercker.yml file into this:
+In order to deploy to GitHub Pages we need to add a deploy pipeline. 
+
+1. First, go to your Wercker application's page. Go to the "Workflows" tab and click on "Add new pipeline." Name it whatever you want; "deploy-production" or "deploy" works fine. For your YML Pipeline name, type in "deploy" without quotes. Leave the hook type as "Default" and hit the Create button. 
+
+2. Now you need to link the deploy pipeline to your build pipeline. In the workflow editor, click on the + next to your build pipeline and add the deploy pipeline you've just made. Now the deploy pipeline will be run automatically whenever the build pipeline is completed successfully.
+
+![][13]
+
+[13]: /img/tutorials/automated-deployments/adding-a-deploy-pipeline.png
+
+## Adding a deploy step
+
+Next, we need to add a step to our deploy pipeline that will deploy the Hugo-built website to your Github pages repository. Once again searching through the Steps registry, we find that the most popular step is the **lukevevier/gh-pages** step so we add the configuration for that to our wercker.yml file. Additionally, we need to ensure that the box we run on has git and ssh installed. We can do this using the **install-packages** command, which then turns the wercker.yml file into this:
 
 ```yaml
 box: debian
@@ -254,19 +260,13 @@ How does the GitHub Pages configuration work? We've selected a couple of things,
 
 Secondly we've configured the basedir to **public**, this is the directory that will be used as the website on GitHub Pages.
 
-And lastly, you can see here that this has a **$GIT_TOKEN** variable. This is used for pushing our changes up to GitHub and we will need to configure this before we can do that. We do this by going to our app's settings and clicking on **Deploy targets**. Now, we **Add deploy target** and select **Custom deploy**.
+And lastly, you can see here that this has a **$GIT_TOKEN** variable. This is used for pushing our changes up to GitHub and we will need to configure this before we can do that. To do this, go to your application page and click on the "Environment" tab. Under Application Environment Variables, put **$GIT_TOKEN** for the Key. Now you'll need to create an access token in GitHub. How to do that is described on a [GitHub help page](https://help.github.com/articles/creating-an-access-token-for-command-line-use/). Copy and paste the access token you generated from Github into the Value box. **Make sure you check Protected** and then hit Add. 
 
-![][15]
+![][14]
 
-[15]: /img/tutorials/automated-deployments/adding-a-github-pages-step.png
+[14]: /img/tutorials/automated-deployments/adding-a-deploy-step.png
 
-## Configure the deploy step
-
-Simply fill in the name, and make sure you enable **auto deploy** from the **master** branch. Next you add a variable for the **GIT_TOKEN**, for this you'll need to create an access token in GitHub. How to do that is described on a [GitHub help page](https://help.github.com/articles/creating-an-access-token-for-command-line-use/). With the deploy step configured in Wercker, we can push the updated wercker.yml file to GitHub and it will create the GitHub pages site for us. The example site we used here is accessible under hugo-wercker.ig.nore.me
-
-![][16]
-
-[16]: /img/tutorials/automated-deployments/configure-the-deploy-step.png
+With the deploy step configured in Wercker, we can push the updated wercker.yml file to GitHub and it will create the GitHub pages site for us. The example site we used here is accessible under hugo-wercker.ig.nore.me
 
 ## Conclusion