| | |
|---|
| | | ## Exercise Intro |
|---|
| | | Build monitors provide a tight feedback loop which is vital to high performing teams. Being in a highly visible location, build monitors radiate crucial build and test information, meaning the team doesn't have to go out of their way to find it. Build monitors also provide a degree of accountability whilst also keeping the team motivated to fix problems. With broken components visualised, seeing build monitors change from red to green can give the collective feeling that progress is being made. |
|---|
| | | |
|---|
| | | On residencies we display the build monitors on Raspberry Pi's hooked up to large TV screens that everyone can see at a glance. We've also used colour-changing lightbulbs in the labs that change from Green to Red depending on the success/fail status of jobs. There are many other ways to notify people of Build Failures such as Slack notices, text messages or just plain old email. This lab is about radiating the information to allow teams respond quickly to change. |
|---|
| | | On residencies we display the build monitors on Raspberry Pi's hooked up to large TV screens that everyone can see at a glance. We've also used colour-changing lightbulbs in the labs that change from Green to Red depending on the success/fail status of jobs. There are many other ways to notify people of Build Failures such as Slack notices, text messages or just plain old email. This exercise is about radiating the information to allow teams respond quickly to change. |
|---|
| | | |
|---|
| | | In this Exercise we will be creating a build monitor to display all of our jobs in one visual display as well as pipeline views. We will then add the cause of build failures for each job to the monitors. This will allow you to rapidly see why a particular build is failing and fix it faster. |
|---|
| | | |
|---|
| | |
|---|
| | | _____ |
|---|
| | | |
|---|
| | | ## 10,000 Ft View |
|---|
| | | > The goal of this exercise is to introduce Build Monitors to radiate teams progress on Dashboards. |
|---|
| | | > The goal of this exercise is to introduce Build Monitors to radiate team's progress on Dashboards. |
|---|
| | | |
|---|
| | | 2. Create a new Dashboard for our Builds using the plugin above. Use Regex to add jobs to it. Use the BuildFail Analyser to add meaningful data to the reason for failures. |
|---|
| | | |
|---|
| | |
|---|
| | | 2. Check the box to use Regular Expression and set the value to be something that should scrape our apps such as `.*todolist.*` |
|---|
| | |  |
|---|
| | | |
|---|
| | | 2. Finally; select `Display committers` and set the Failure Analyser to `Description`. This allows us to write regex for when fails occur in Jenkins and have the reasons plotted on the graph. For example; number of test scores or common compilation errors. |
|---|
| | | 2. Finally; select `Display committers` and set the Failure Analyser to `Description`. This allows us to write regexes for when failures occur in Jenkins and have the reasons plotted on the graph. For example; number of test scores or common compilation errors. |
|---|
| | |  |
|---|
| | | |
|---|
| | | 2. Save your configuration to see your Build Monitor! |
|---|
| | |
|---|
| | | |
|---|
| | | 2. Open the `todolist-fe` app in your favourite editor. In this exercise, we will fail a test and capture the message in the log and visualise it on a dashboard. |
|---|
| | | |
|---|
| | | 2. Open one of the tests you wrote in previous labs; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file by adding a `.not` to the `expect()` statement as shown below. |
|---|
| | | 2. Open one of the tests you wrote in previous exercises; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file by adding a `.not` to the `expect()` statement as shown below. |
|---|
| | | ```javascript |
|---|
| | | it("call makImportant when clicked", () => { |
|---|
| | | const wrapper = mount(TodoItem, { |
|---|
| | |
|---|
| | | |
|---|
| | | 2. Our dashboards are set to show the `Description` field from the `Build Fail Analyser`. Run a build by checking in our failed tests and check the result on the Build Monitor created in the previous step |
|---|
| | | ```bash |
|---|
| | | $ git add . |
|---|
| | | $ git commit -m "TEST - failing build" |
|---|
| | | $ git push |
|---|
| | | git add . |
|---|
| | | ``` |
|---|
| | | ```bash |
|---|
| | | git commit -m "TEST - failing build" |
|---|
| | | ``` |
|---|
| | | ```bash |
|---|
| | | git push |
|---|
| | | ``` |
|---|
| | |  |
|---|
| | | |
|---|
| | | 2. We can save up these regex and inject them into the `jenkins-s2i` so the configuration is there the next time we launch and we don't have to code them up again. In `enablement-ci-cd` repo; the `jenkins-s2i/configuration/build-failure-analyzer.xml` already contains ones we've collected on previous residencies. |
|---|
| | | 2. We can save up these regexes and inject them into the `jenkins-s2i` so the configuration is there the next time we launch and we don't have to code them up again. In `enablement-ci-cd` repo; the `jenkins-s2i/configuration/build-failure-analyzer.xml` already contains ones we've collected on previous residencies. |
|---|
| | | |
|---|
| | | ### Part 3 - Seed Jenkins Dashboards |
|---|
| | | > _TODO - Add instructions for creating dashboards as part of s2i in Jenkins setup using DSL_ |
|---|
| | |
|---|
| | | - Add `Slack` integration to the Pipeline by setting up a WebHook to call the slack endpoint with Build Stats |
|---|
| | | - Add `Twillio` text integration to send you text messages when the build fails. |
|---|
| | | Additional Monitoring |
|---|
| | | - Explore the Application's FEK stack inside OpenShift |
|---|
| | | - Explore the Application's EFK stack inside OpenShift |
|---|
| | | |
|---|
| | | ## Additional Reading |
|---|
| | | > List of links or other reading that might be of use / reference for the exercise |
|---|
