| exercises/1-the-manual-menace/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/2-attack-of-the-pipelines/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/3-revenge-of-the-automated-testing/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/4-an-enslaved-hope/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/exercise-layout-template/README.md | ●●●●● patch | view | raw | blame | history |
exercises/1-the-manual-menace/README.md
@@ -199,7 +199,7 @@ MEMORY_LIMIT=1Gi ``` 4. Create a new object in the inventory variables `inventory/host_vars/ci-cd-tooling.yml` called `ci-cd-tooling` and populate it's `content` is as follows 4. Create a new object in the inventory variables `inventory/host_vars/ci-cd-tooling.yml` called `ci-cd-tooling` and populate its `content` is as follows ```yaml --- @@ -216,7 +216,7 @@ ```  4. Run the OpenShift applier, specifying the tag `nexus` to speed up it's execution (`-e target=tools` is to run the other inventory). 4. Run the OpenShift applier, specifying the tag `nexus` to speed up its execution (`-e target=tools` is to run the other inventory). ```bash ansible-playbook apply.yml -e target=tools \ -i inventory/ \ @@ -277,7 +277,7 @@ - gitlab ``` 4. Run the OpenShift applier, specifying the tag `gitlab` to speed up it's execution. 4. Run the OpenShift applier, specifying the tag `gitlab` to speed up its execution. ```bash ansible-playbook apply.yml -e target=tools \ -i inventory/ \ exercises/2-attack-of-the-pipelines/README.md
@@ -58,8 +58,8 @@ 5. Trigger the `bake` job with the `${BUILD_TAG}` param * a `Bake` job should take the package and put it in a Linux Container 1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`. 2. Checkout the binary from Nexus and unzip it's contents 3. Run an oc start-build of the App's BuildConfig and tag it's imagestream with the provided `${BUILD_TAG}` 2. Checkout the binary from Nexus and unzip its contents 3. Run an oc start-build of the App's BuildConfig and tag its imagestream with the provided `${BUILD_TAG}` 4. Trigger a deploy job using the parameter `${BUILD_TAG}` * a `deploy` job should roll out the changes by updating the image tag in the DC: 1. Take an input of the `${BUILD_TAG}` @@ -96,7 +96,7 @@ git checkout develop ``` 2. Open up Gitlab and login. Create a new project (internal) in GitLab called `todolist-fe` to host your clone of the project and copy it's remote address.  2. Open up Gitlab and login. Create a new project (internal) in GitLab called `todolist-fe` to host your clone of the project and copy its remote address.  2. In your local clone of the `todolist-fe`, remove the origin and add the GitLab origin by replacing `<YOUR_GIT_LAB_PROJECT>`. Push your app to GitLab ```bash @@ -116,7 +116,7 @@ </p>  2. The `todolist-fe` has a package.json at the root of the project, this defines some configuration for the app including it's dependencies, dev dependencies, scripts and other configuration. Install the apps dependencies 2. The `todolist-fe` has a package.json at the root of the project, this defines some configuration for the app including its dependencies, dev dependencies, scripts and other configuration. Install the apps dependencies ```bash npm install ``` @@ -212,7 +212,7 @@ git checkout develop ``` 2. On GitLab; create a new project (internal) called `todolist-api` to host your clone of the project and copy it's remote address as you did for the previous repositories. 2. On GitLab; create a new project (internal) called `todolist-api` to host your clone of the project and copy its remote address as you did for the previous repositories. 2. In your local clone of the `todolist-api`, remove the origin and add the GitLab origin by replacing `<YOUR_GIT_LAB_PROJECT>`. Push your app to GitLab ```bash @@ -441,8 +441,8 @@ 5. Trigger the `bake` job with the `${BUILD_TAG}` param * a *bake* job should take the package and put it in a Linux Container 1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`. 2. Checkout the binary from Nexus and unzip it's contents 3. Run an oc start-build of the App's BuildConfig and tag it's imagestream with the provided `${BUILD_TAG}` 2. Checkout the binary from Nexus and unzip its contents 3. Run an oc start-build of the App's BuildConfig and tag its imagestream with the provided `${BUILD_TAG}` 4. Trigger a deploy job using the parameter `${BUILD_TAG}` * a *deploy* job should roll out the changes by updating the image tag in the DC: 1. Take an input of the `${BUILD_TAG}` @@ -575,7 +575,7 @@ ```  5. When a deployment has completed; OpenShift can verify it's success. Add another step by clicking the `Add build Step` on the Build tab then `Verify OpenShift Deployment` including the following: 5. When a deployment has completed; OpenShift can verify its success. Add another step by clicking the `Add build Step` on the Build tab then `Verify OpenShift Deployment` including the following: * Set the Project to your `<YOUR_NAME>-dev` * Set the DeploymentConfig to your app's name `todolist-fe` * Set the replica count to `1` exercises/3-revenge-of-the-automated-testing/README.md
@@ -71,7 +71,7 @@ ## 10,000 Ft View > The goal of this exercise is to add a new component to the application using TDD to create and validate it's behaviour. The User story we have been given is as follows: > The goal of this exercise is to add a new component to the application using TDD to create and validate its behaviour. The User story we have been given is as follows: *As a doer I want to mark todos as important so that I can keep track of and complete high priority todos first* @@ -344,7 +344,7 @@ Our TodoList App uses `vuex` to manage the state of the apps' todos and `axios` HTTP library to connect to the backend. `Vuex` is an opinionated framework for managing application state and has some key design features you will need to know to continue with the exercise. In `vuex` the application state is managed by a `store`. The `store` houses all the todos we have retrieved from the backend as well as the `getter` methods for our array of `todos`. In order to make changes to the store, we could call the store directly and update each todo item but as earlier said; vuex is an opinionated module with it's own way of updating the store. It is bad practice to call the store directly. In `vuex` the application state is managed by a `store`. The `store` houses all the todos we have retrieved from the backend as well as the `getter` methods for our array of `todos`. In order to make changes to the store, we could call the store directly and update each todo item but as earlier said; vuex is an opinionated module with its own way of updating the store. It is bad practice to call the store directly. There are two parts of the lifecycle to updating the store, the `actions` & `mutations`. When the user clicks a todo to mark it as complete; the `actions` are called. An action could involve a call to the backend or some pre-processing of the data. Once this is done, the change is committed to the store by calling the `mutation` function. A store should only ever be manipulated through a mutation function. Calling the mutation will then update the todo object in the apps local store for rendering in the view. @@ -377,7 +377,7 @@ 3. There are three places we will add new tests to validate our function behaves as expected against the acceptance criteria from the Feature Story supplied to us. We will need to write tests for our `TodoItem.vue` to handle having a red flag and that it is clickable. Our app is going to need to persist the changes in the backend so we'll want to make changes to our `actions.js` and `mutations.js` to keep the api and local copy of the store in sync. Let's start with our `TodoItem.vue` component. Open the `tests/unit/vue-components/TodoItem.spec.js` file. This has been templated with some example test to correspond with our A/Cs for speed of doing the exercise. Find the describe block for our important flag tests. It is setup already with a `beforeEach()` hook for test setup.  3. Each of our test cases has it's skeleton in place already for example the `TodoItem.vue` component takes a property of `todos` when rendering. This setup is already done for each of our tests so all we have to do is fill in our assertions. 3. Each of our test cases has its skeleton in place already for example the `TodoItem.vue` component takes a property of `todos` when rendering. This setup is already done for each of our tests so all we have to do is fill in our assertions.  3. Let's implement the first test `it("should render a button with important flag"`. This test will assert if the button is present on the page and it contains the `.important-flag` CSS class. To implement this; add the `expect` statement as follows below the `// TODO - test goes here!` comment. exercises/4-an-enslaved-hope/README.md
@@ -6,7 +6,7 @@ There are a number of ways pipeline as code can be achieved in Jenkins. * The Job DSL Plugin - this is a slightly older but very functional DSL mechanism to create reusable pipelines. Create a `groovy` file to run Jenkins Domain Specific Language to create jobs, functions and other items. In Jenkins; you then can execute this file which will build all of the config.xml files needed for each Job. * The Scripted Pipeline - The scripted pipeline introduced the Jenkinsfile and the ability for developers to write their Jenkins setup as groovy code. A repo with a Jenkinsfile in it's root can be pointed to by Jenkins and it will automatically build out each of the stages described within. The scripted pipeline is ultimately Groovy at it's core. * The Scripted Pipeline - The scripted pipeline introduced the Jenkinsfile and the ability for developers to write their Jenkins setup as groovy code. A repo with a Jenkinsfile in its root can be pointed to by Jenkins and it will automatically build out each of the stages described within. The scripted pipeline is ultimately Groovy at its core. * The Declarative Pipeline - This approach looks to simplify and opinionate what you can do and when you can do it in a pipeline. It does this by giving you top level `block` which define sections, directives and steps. The declarative syntax is not run as groovy but you can execute groovy inside script blocks. The advantage of it over scripted is validation of the config and lighter approach with requirement to understand all of the `groovy` syntax _____ exercises/README.md
@@ -3,7 +3,7 @@  This is a collection of practices and exercises to take a learner through a four day simulated residency experience. Learners can expect to be exposed to labs practices such as [Event Storming](https://rht-labs.github.io/practice-library/practices/event-storming/), [Social Contract](https://rht-labs.github.io/practice-library/practices/social-contract/) and [Impact Mapping](https://rht-labs.github.io/practice-library/practices/impact-mapping/) amoung many more which can be found in our [Practice Library](https://rht-labs.github.io/practice-library/). Learners will also be exposed to `Labs CI/CD` - how we use OpenShift & Ansible in conjunction with Jenkins to automate build and deploy of a sample todolist application and it's required infrastructure. This is a collection of practices and exercises to take a learner through a four day simulated residency experience. Learners can expect to be exposed to labs practices such as [Event Storming](https://rht-labs.github.io/practice-library/practices/event-storming/), [Social Contract](https://rht-labs.github.io/practice-library/practices/social-contract/) and [Impact Mapping](https://rht-labs.github.io/practice-library/practices/impact-mapping/) amoung many more which can be found in our [Practice Library](https://rht-labs.github.io/practice-library/). Learners will also be exposed to `Labs CI/CD` - how we use OpenShift & Ansible in conjunction with Jenkins to automate build and deploy of a sample todolist application and its required infrastructure. ## Learner pre-requisites - OCP CLI v3.9 @@ -14,7 +14,7 @@ - Docker latest - JDK v8 - Access to an OpenShift cluster `oc login -u <username> -p <password> <cluster_url>` - Text editor such as Atom, IntelliJ or Visual Studio Code (The exercise were created using VSCode, so the screenshots will match it's layout and colour schemes) - Text editor such as Atom, IntelliJ or Visual Studio Code (The exercise were created using VSCode, so the screenshots will match its layout and colour schemes) > (TODO) Download the tools-container containing required Ansible and OpenShift tooling pre-installed
@@ -1,6 +1,6 @@ # Exercise Title > Short description of the exercise and it's outcomes > Short description of the exercise and its outcomes _____ ## Learning Outcomes @@ -57,4 +57,4 @@ > List of links or other reading that might be of use / reference for the exercise ## Slide links > link back to the deck for the supporting material > link back to the deck for the supporting material
