diff --git a/01 Professional Development.md b/01 Professional Development.md new file mode 100644 index 0000000..837f4b6 --- /dev/null +++ b/01 Professional Development.md @@ -0,0 +1,72 @@ + +# Professional Development + +Each week you will be expected to complete a series of lab activities in your two lab sessions. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +Resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/1qqetvLVMWvNGsmyGr9-Cuooxpz0Vl2OnD0oionqPOdI/edit) +2. Microsoft Teams installation files: + 1. [Official app](https://teams.microsoft.com/downloads) for MacOS and Windows 10. + 2. [Unofficial app](https://github.com/IsmaelMartinez/teams-for-linux) for Linux. + +## 1 Teams + +The agile teams have been set up to contain students with the range of skills needed to complete the module. Each team is named after an animal. Check the team list which you will find at the front of the lab to find out which team you have been assigned to and which lab slots you will need to attend (these should also be shown on your University timetable). + +1. Each team needs a catch phrase! Discuss and agree one for your team. +2. Early on in the _first lab session_ email any members of your team who have not turned up to remind them to attend. It it very important that you meet up _every scheduled lab_ to avoid falling behind! You will find their email addresses in the University Email address book. + +## 2 Project + +Make sure you understand the group project topic. Ask your _lab supervisors_ if you have any questions. The product is only worth **10%** of your final grade however the skills and knowledge you acquire by completing the weekly lab worksheets will be needed to complete the reflective report (40%) and revise for the phase test (50%). + +Carry out a brainstorm to make a list of all the interesting outcomes you could produce. You can find a list of the items in the IoT kit in the `exercises/` directory in the teaching materials on GitHub. + +The implementation will consist of three key parts: + +1. A "home hub" that contains the core business logic and handles the communications between the sensors/actuators and the UI. This could be a small computer running Linux (such as a Raspberry Pi) or a powerful microcontroller. +2. Some sensors and actuators that communicate with the hub. Each will need its own microcontroller and you will need to decide how it will wirelessly communicate with the hub. +3. Some form of UI that the homeowners can interact with. Will this be a web page, app or both? + +Discuss the technical strengths and weaknesses of your team members and, before the end of the first lab session make some tentative choices as to which part each person is best placed to work on. We will come back to this in the second lab. + +## 3 Skills Audit + +Perform a detailed analysis of the problem you are going to solve and perform a Skills Audit on your team. There are a list of generic skills listed in the presentation which you will need to supplement with skills related to your choice of project. use this [skills list](exercises/01_prof_dev/README.md) as a starting point. + +Create a **Team Competency Matrix** using a simple **Red-Amber-Green** (RAG) scale as shown in the lecture. This should include skills taken from the [skills list](exercises/01_prof_dev/README.md) provided plus any others you feel might be useful. + +Refine the matrix using a 5 point scale. + +## 4 Professional Development Plan + +This should be carried out in the second lab session in small groups of 2 or 3. In these smaller groups, develop a **Professional Development Plan** for each person who should identify three things they feel they need to learn before the start of the development process in week 3 (so don't be too ambitious). + +Create a top level heading for each of your chosen three topics and, for each, work together to answer the following questions, writing down the answers: + +1. What do I want to learn? +2. What will I do to achieve this? +3. What resources and support will I need? +4. What will my success criteria be? + +We will be reviewing this document in week 4 so keep it safe and refer to it as you carry out your learning. + +As you carry out your learning to support this, answer the following, writing the answers down as you do each piece of learning: + +1. What did you do? +2. Why? +3. What did you learn from this? +4. How will you be able to use this in the team project? + +## 5 Team Psychology + +Since we did not cover this in the lecture you should not attempt this task. We will come back to it in week 4. + +You have been introduced to a number of important (and potentially interesting?) areas of psychology that relate to group behaviour. As a group: + +1. Discuss the 'symptoms' of each (what should you be looking out for)? +2. What is the short-term impact on the team? +3. If not addressed what might be the longer-term impact? Is it recoverable at this stage? +4. What can be done to _prevent_ this from ocurring? +5. What can be done to recover it it occurs? diff --git a/02 Team Psychology.md b/02 Team Psychology.md new file mode 100644 index 0000000..ca50bfc --- /dev/null +++ b/02 Team Psychology.md @@ -0,0 +1,53 @@ + +# Team Psychology + +This week is for you and your team to take a deep breath after an intense week where you attempted to build a simple smarthome system. Despite the task seeming to be relatively simple on paper you will have struggled to get it completed. This lab you will be reflecting on why this was the case. + +Resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/1_mMYilNPr1QCobs1wGp_Z6e8JyNJsOazRKAQkWbghwQ/edit?usp=sharing) + +## 1 Reflection + +Once you are all logged into the MS Teams portal you should reflect on the technical work your team carried out last week. Discuss the following points and make notes: + +1. What went well? +2. What challenges did you face? +3. What will you change next time your team works on the project? +4. Were there any skills missing from the team and how did this impact the project? + +## 2 CPD Peer Review + +During the first week you put together a document that describes three skills you have agreed to learn. Locate this document and put yourself in a small group of 2 or three away from the rest of the team. Make sure the other members of your team _don't_ have the same skill set! Print off enough copies of your CPD plan to give to the all the members of our small group (including one for yourself). + +1. Put all smartphones on silent and place them in your pockets. +2. Put all laptops in their bags and make sure any computer monitors are off. +3. Each person in the small group should go through their plan, discuss these points and make notes on the printout: + 1. Was the skill relevent to the project? + 2. Did they learn the skill? + 3. What three skills do they want to learn over the next three weeks? +4. Next, each member should create a fresh CPD plan using the headings from the week 1 lab exercise. Once complete, this document should be shared via the OneDrive folder on MS teams, you will be returning to this in 3 weeks time. + +## 3 DiSC Personality Test + +Your next task is to complete the online [DiSK personality test](https://www.123test.com/disc-personality-test/). Consider your DiSC profile, does this reflect you as a person and how you interact with the rest of the team? As a team compare your profiles and discuss how this information helps you reflect on the team interactions. + +## 4 Team Psychology + +As a group, review the materials on team psychology from the lecture: + +1. Did your group exhibit any known psychologicsl traits? +2. Why did these occur? +3. What team roles (Belbin) did members demonstrate? +4. Where on the Team Development Model (Tuckman) are you as a team? +5. By labelling these traits you should be able to search for strategies your team can employ to prevent them happening again. + +## 5 Demonstration + +The first task is to set up your system and show the lab tutor what you got working. You will be doing this even if your system is not 'complete'. If the lab supervisor is busy with another team, get the system set up and start working on task 2 while you are waiting. + +## 6 Microsoft Teams + +Next, all the group members should install MS Teams on their smartphones (and laptops if possible) and log in using their university email and password. Once logged in, everyone will find they have been placed in a team. If you are not in a team or in the wrong team, let the lab supervisor know immediately. + +Next week you will be learning about the **Scum** methodology and applying it to your development team. diff --git a/03 Scrum.md b/03 Scrum.md new file mode 100644 index 0000000..534651f --- /dev/null +++ b/03 Scrum.md @@ -0,0 +1,98 @@ + +# Scrum + +This week you will be applying the Scrum methodology to improve the effectiveness of your team. Because you have already troubleshooted all the driver and connectivity issues, your team should be able to make some real progress this week. + +Resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/1prJugx0CP3dDd5j5BqpD40mTwtzh3Ki91N2jCWagc_s/edit?usp=sharing) + +## 1 The Task + +This week your task is as follows: + +**As a home owner I want an automated lighting system so that the lights come on if there is not enough natural light.** + +This can be broken down into a number of features: + +1. The system should include an interior light and an exterior light for people approaching the front door. +2. Each light should be independently controlled. +3. The lights should not come on automatically unless the natural lighting levels are too low. +4. The threshold should be set by the user and this can differ for different lights. +5. The light should switch off if no movement is detected for 10min by default but this interval should be user definable. +6. The user should be able to override the indoor light system and switch the lights on and off using a light switch (push button). +7. The system should keep a record of when the outdoor light is triggered, to include the date/time when it switched on and off. + +## 2 Planning Poker + +Your first task for your team is to figure out the different tasks that will be needed to be completed in order to implement this feature. You should be as detailed as possible, breaking the work down into manageable chunks, writing each task on a post-it note. + +Next, one member of the team should read out the task and everyone should secretly decide how long the task will take in hours, holding up their fingers behind their backs to make their choice (with 5 fingers indicating 5 hours or more). The team should then simultaneously reveal their choices and, at this stage one of the three options below will happen: + +1. Everyone picks the same number of hours and this is 4 hours or less, write this on the note and move on to the next task. +2. Everyone picks the same number but it is over 4 hours, the team split the task into two tasks, adding these to the stack and throwing away the bigger task. +3. Members of the team pick different durations, the person with the lowest estimate explains the rationale behind their choice as does the person with the highest, then the team vote again and repeat this until they agree. + +## 3 Burndown + +Next, the total number of hours of work needed are added up and this used to produce a burndown chart. The x axis represents the amount of work (this will depend on the hours calculated) and the y axis is the number of days the team will be working (4 days, Tuesday to Friday) in this case. Calculate the necessary burn rate by dividing the total hours of work by 4. This tells the team how many task hours will need to be completed each day if the team are not to fall behind. This can be represented by a straight line from the end of the x axis to the end of the y axis as shown below. + +Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day. + +``` + 40 ║* + ║ * + 30 ║ * + ║ * + 20 ║ * + ║ * + 10 ║ * + ║ * + 00 ║ * + ╚══════════════════════════ + M T W T F +``` + +## 4 Kanban Board + +The next step is to draw a kanban board (perhaps either on a whiteboard or flipchart paper). Use the column headings below as a guide. Now add all the tasks to the todo column as shown. + +``` +╔══════════════╦══════════════╦══════════════╦══════════════╦══════════════╗ +║ To Do ║ Plan ║ Implement ║ Test ║ Done ║ +╟──────────────╫──────────────╫──────────────╫──────────────╫──────────────╢ +║ ┌────────┐ ║ ║ ║ ║ ║ +║ │ │ ║ ║ ║ ║ ║ +║ └────────┘ ║ ║ ║ ║ ║ +║ ┌────────┐ ║ ║ ║ ║ ║ +║ │ │ ║ ║ ║ ║ ║ +║ └────────┘ ║ ║ ║ ║ ║ +║ ┌────────┐ ║ ║ ║ ║ ║ +║ │ │ ║ ║ ║ ║ ║ +║ └────────┘ ║ ║ ║ ║ ║ +║ ┌────────┐ ║ ║ ║ ║ ║ +║ │ │ ║ ║ ║ ║ ║ +║ └────────┘ ║ ║ ║ ║ ║ +╚══════════════╩══════════════╩══════════════╩══════════════╩══════════════╝ +``` + +## 5 Assign Roles + +You now need to discuss who will be taking on the role of Scrum Master and who will be the Product Owner. Refer to the lecture slides if you need reminding of their respective roles. + +## 6 Daily Stand-Up Meeting + +Now all the planning is done you are ready to start development. Stand in a huddle and make sure everyone can see both the updated burndown chart and kanban board. The Scrum Master should go around the group and ask each person in turn to answer the following three questions, taking a maximum of 90 seconds to answer all three: + +1. What task(s) have I done since the last standup meeting (are these clearly shown as complete)? +2. What am I planning on/agreeing to do before the next meeting (make sure the person writes their name on these and moves them to the **Plan** column on the board)? +3. Are there any issues that are stopping me from completing these tasks (the Scum Master should note these down)? + +Now thw meeting is over but, whilst the rest of the team are getting back to work, the Scrum Master needs to review the answers to question 3 and figure out how they can be fixed. They might at this stage consult the specialists on the team and, after putting a plan together inform the person who raised the issue explaining how it will be resolved. + + +## 7 Conducting the Sprint + +You will need to organise a daily standup meeting every morming between now and Friday. Decide on the times and how it will be conducted (face to face or video call). If you choose to use a video call make sure everyone can access it and conduct a quick group call during the lab to avoid technical issues later. + +Next week you will be expected to demonstrate working software to the lab tutor. \ No newline at end of file diff --git a/04 Communication.md b/04 Communication.md new file mode 100644 index 0000000..27c0293 --- /dev/null +++ b/04 Communication.md @@ -0,0 +1,61 @@ + +# Communication + +This lab is to get you and your team to focus on managing your communication be effectively employing the core agile tools: + +1. The Kanban board +2. The Burndown chart +3. Daily standups + +## 1. User Stories + +The first task for the entire team is to create user stories for the features they want to include in the home automation system. These should be in the format: + +As a **ROLE** I want to be able to **PURPOSE** so that **JUSTIFICATION**. + +You should create a word document called **User Stories** under the documents tab in your MS Teams page and carefully record these. + +## 2. Team Structure + +During this lab you will be organising the team into two smaller teams of between 3 and 4 members. If you existing team is only small (up to 5) you don't need to carry out this step. + +Start by picking team names, these should be sub-species of the main team's animal, for example Tabby or Spaniel. + +To ensure both smaller teams are equally balanced, start by appointing a _scrum master_ for each team who should create a new Team in MS Teams. Let them both have access to an up to date skills competency matrix and take it in turns to pick members, making sure they have all the key positions filled. Once the teams are selected, the members of each should be added to the new Team in MS Teams. + +Each team should now pick one of the user stories to work on over the next 2 weeks, making a note in the document to show which one they have picked. From this point onwards each team will work independently. + +## 3. Daily Standup + +Since the team is much smaller, you should find it easier to find a common timeslot each day to carry out the 15 minute standup meeting (in fact with the team much smaller you might not need so long). Discuss what time suits, given you will need to meet at this time _every day_. Once this has been agreed you need to use MS Teams to set up a recurring video slot. + +## 4. Domain-Specific Language + +Now each team should take their chosen user story and create a textfile with a `.feature` extension. In this they should define the problem using the [Gherkin](https://www.tutorialspoint.com/cucumber/index.htm) DSL. This should include: + +1. The feature (user story). +2. The scenarios (functional requirements). +3. The annotations (steps to achieve each functional requirement). +4. Tags (to organise the information). + +When your small team is happy with the feature you should use a tool such as [FeatureBook](https://www.npmjs.com/package/featurebook) to build your documentation. It would be a good idea to generate a printable PDF and print copies of this ready for the next task. + +## 5. The Kanban Board + +Each team will need to create a Kanban tab in their project space, this is an instance of a **Planner** document. Create three columns as shown in the lecture slides, _To Do_, _In Progress_ and _Done_. Distribute copies of the specification (from the previous step) and work together to define a list of the small tasks needed to complete it. These should be entered as tasks directly into the _To Do_ column of the board but not assigned to anyone. + +Now each person in the team should pick a task, drag it to the middle _In Progress_ and assign it to themselves (this should not be done by the Scrum Master). As they finish a task it should be moved to the _Done_ column and checked to show it is finished. The person should then pick another task from the first column, assign it to themselves and move to the middle column. + +## 6. The Daily Standup + +Please make sure you all connect to the online standup at the appointed time. If you have the MS Teams app installed you will see the meetings in your calendar and set a reminder. Once you are connected (with camera and microphone enabled) you should each answer the following questions: + +1. What have I done since the last meeting (yesterday)? If you were unable to do anything be honest about it and give your reasons. +2. What will I aim to complete before the next meeting (tomorrow)? Again, if you can't spend any time on the project its best to be open and honest. +3. Have you encountered any problems? + +Once everyone has finished, the Scrum Master should review the progress (burndown) using the two charts in the Kanban board and let the team know whether the project is ahead or behind schedule and by how much. + +There is a recorder tool in MS Teams which will allow you to record the video meeting. You should make use of this to record a couple of the meetings and review then later to help improve your technique. + +There is a screen sharing feature in MS Teams, the Scrum Master should use this to update the team during the meetings by displaying the Kanban board and burndown/progress charts. diff --git a/05 Kanban Boards.md b/05 Kanban Boards.md new file mode 100644 index 0000000..32b738d --- /dev/null +++ b/05 Kanban Boards.md @@ -0,0 +1,96 @@ + +# Kanban Boards + +First sprint. + +### 2.1 The Kanban Board + +For this first sprint, your Kanban board should have a row for each of the user stories you have chosen to deliver and 4 columns as shown: + +``` +╔═════════╦════════════════╦════════════════╦════════════════╦════════════════╗ +║ Story ║ To Do ║ Planning ║ Implementation ║ Done ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╚═════════╩════════════════╩════════════════╩════════════════╩════════════════╝ +``` + +At the start of the sprint, all tasks should be in the **To Do**. By the end of the sprint, all tasks should be in the **Done** column. + +### 2.2 The Burndown Chart + +Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day. + +``` + 40 ║* + ║ * + 30 ║ * + ║ * + 20 ║ * + ║ * + 10 ║ * + ║ * + 00 ║ * + ╚══════════════════════════ + M T W T F +``` + + +### 2.1 The Kanban Board + +For this first sprint, your Kanban board should have a row for each of the user stories you have chosen to deliver and 4 columns as shown: + +``` +╔═════════╦════════════════╦════════════════╦════════════════╦════════════════╗ +║ Story ║ To Do ║ Planning ║ Implementation ║ Done ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╚═════════╩════════════════╩════════════════╩════════════════╩════════════════╝ +``` + +At the start of the sprint, all tasks should be in the **To Do**. By the end of the sprint, all tasks should be in the **Done** column. + +``` +╔═══════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╗ +║ Story ║ To Do ║ Plan ║ Tests ║ Implement ║ Refactor ║ Regressn ║ Done ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ A ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ a │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ B ║ ║ ║ ║ ┌───────┐ ║ ║ ║ ║ +║ ║ ║ ║ ║ │ b │ ║ ║ ║ ║ +║ ║ ║ ║ ║ └───────┘ ║ ║ ║ ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ C ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ c │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +║ ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ d │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +╚═══════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╝ +``` diff --git a/06 Burndown Charts.md b/06 Burndown Charts.md new file mode 100644 index 0000000..54571d5 --- /dev/null +++ b/06 Burndown Charts.md @@ -0,0 +1,57 @@ + +# Burndown Charts + +Resources: + +1. [Lecture slides](https://drive.google.com/open?id=1SS9593YC-Y38hQ1Ru9kH6mMtBAq5if656jN-Z0QISRI) + +# 1 Sprint Review + +At this stage you have completed your first sprint making use of a Kanban board. During the first lab schedule a 30min meeting with the client (lab tutor) to perform a review meeting and the planning meeting for your second sprint. + +Before this meeting: + +1. Check that the product demo will run correctly. + +During the review meeting you should follow the following steps: + +1. The product owner should discuss the user story you completed last sprint and run a demo to demonstrate ot works. +2. Let the client give you feedback and add any points raised as GitHub issues. + +# 2 Sprint Planning Meeting + +This should commence at the end of the review session. + +1. Discuss the remaining user stories in the left column of the KanBan and, working with the client decide on the updated priorities. +2. Take the top story and discuss this with the client to gain an understanding as to the detailed requirements. The product owner should ensure this is documented using diagrams and notes. It is probably easiest to produce these on paper and photo or scan afterwards. +3. All notes to be digitised and added as comments to the user story. + +Once the client has departed: + +1. Any issues raised during the review should be added to the **To do** column in the Kanban. +2. The detailed notes should be used to break the story into small tasks and added to the To do column. +3. The team should play planning poker to estimate how long each task should take: + 1. Use 1-4 fingers to indicate the number of hours. If there is a difference in estimation between the team members take a few minutes to understand why thenvote again. + 2. If you think it will take longer display all 5 fingers. This wil trigger a discussion on how it can be broken into smaller tasks. + 3. Add the agreed estimation to the task. +4. The Scrum Master adds up all the estimated durations and uses this to construct the burndown chart. + 1. You will have to agree how many days (daily standup meetings) you will need. + 2. From this you can calculate the optimal burn rate (how many of the estimated hours need to be completed each day). + +## 2.1 An Example Burndown Chart + +Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day. + +``` + 40 ║* + ║ * + 30 ║ * + ║ * + 20 ║ * + ║ * + 10 ║ * + ║ * + 00 ║ * + ╚══════════════════════════ + M T W T F +``` diff --git a/07 Co-Working.md b/07 Co-Working.md new file mode 100644 index 0000000..1f9db09 --- /dev/null +++ b/07 Co-Working.md @@ -0,0 +1,51 @@ + +# Co-Working + +In this final lab you will be applying all the skills you have learned so far but in a distributed environment. You first step should be to locate a suitable co-working space that is convenient for you to commute to, this might be: + +1. A suitable cafe near your house. +2. A cafe in the university such as the ones in the health buildings. +3. There is a co-working space on the ground floor of the the Alan Berry building. +4. There is co-working space in the council house building (The Wheelhouse). + +Now you need to discuss with the rest of your team whether you will: + +1. Start a new user story. +2. Complete a story you have already started. + +Whatever option you choose, take the time to make sure all the tasks are as small as you can manage and are added to the Kanban board. + +Now conduct your daily standup meeting with each person moving a task to the middle column, making it as _in progress_ and discussing any issues. + +Agree on what time each day you will be scheduling your daily standup and the Scrum master should create a repeating meeting schedule. Remember the absolute last day of the sprint will be next Monday (there will be no lecture). + +## Lab Support + +Both lab tutors are available via MS Teams on Tuesday and wednesday 09:00-13:00. You can request audio or video calls or message them for support. + +## Registers + +The lab tutors will be monitoring the participation of the team members. If you participate in every daily standup (we can see the logs) you will be recorded as having attended both your weekly lab sessions. + +## Recording the Demo + +Next Tuesday you will need to find time to record and edit your 3 min video demo. This will need to start with the team logo. There are lots of suitable video editors including some that can be installed on your phone. Use this list to get you started: + +- Macos / iOS: iMovie +- Windows: Movie Creator +- Linux: ShotCut +- Android: Adobe Premiere Clip + +When the video is complete and the team are happy, upload this to your team area in MS Teams. + +## Returning the Kits + +One member of each team signed for the kit at the start of the module. Once the video as been created and uploaded please dismantle the kit, check the inventory and return the kit to the lab supervisor at the start of your final lab session (Wednesday or Friday). + +## Continuing Professional Development + +Towards the end of the sprint you should review your last professional development plan and identify which of the three skill areas you have improved and how you did this. Finally reflect on your experiences and skills and identify a final list of three skill areas you feel you would like to work on before you start your first job or return on the Masters programme. + +## Uploading the Reflective Report + +The deadline for the reflective report is in May, after the Disssertation submission however you may decide the submit this early whilst things are still fresh in your mind. If you submit the report before the end of the semester you will get your final (provisional) module mark the following week. diff --git a/08 Domain-Driven Design.md b/08 Domain-Driven Design.md new file mode 100644 index 0000000..e505606 --- /dev/null +++ b/08 Domain-Driven Design.md @@ -0,0 +1,34 @@ + +# Domain-Driven Design + +Supporting resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/15roChBN5xnttLZYg7Wdk7b26W5Q23nCYNycLj8GNy5w/edit?usp=sharing) + +In this lab you will be exploring the software domain for your assignment scenario. By the end of the lab you will have build a detailed model of the domain to that shows your understanding. + +You should complete the following steps, either in a small group or on your own: + +1. Describe the domain depicted in your scenario. This should be in the form of between 6 and 12 sentences in plain English that include the key terms commonly used in the domain _but no technical language at all_. There is an example on lecture slide 45 (the link to the presentation can be found at the top of this lab). This simulates the notes you would be taking in an early meeting with your client. +2. Extract the **Domain Language** and carefully define what is meant by each of the terms and expressions _in the context your your domain_. Be sure you remove any ambiguity. This simulates a detailed and probing discussion with the client. +3. Finally you should use the information you have recorded so far to build a class diagram. This should include: + 1. The domain classes (or artefacts). + 2. Key attributes of each class (but only list the ones that directly relate to the domain discussed, this is not meant to be a database schema!). + 3. The associations between each class or artefact. Optionally you can also specify the multiplicity of each. + +This exercise will probably take one complete lab. For the rest of the week you should ensure you have completed the core labs from previous weeks in readyness for the start of the build next week. These labs are: + +1. Setup (plus local setup if you plan on using your own laptop). +2. Templates and forms. +3. Dynamic websites. +4. TDD and Express. + +The extra labs will help you during the build and, if time allows, you should complete the following: + +1. TDD and APIs (especially if you are studying 304CEM). +2. TDD and JavaScript, to help you implement TDD for code running in the browser. +3. Async JavaScript which will improve your code structure and layout by introducing some of the more advanced JavaScript asynchronous constructs. + +## Assessment + +The domain description and domain language should be included in the report as appendix A. This will not count towards your word-count. The domain model (class diagram) should be included in the report and form part of the system analysis. diff --git a/09 Architecture.md b/09 Architecture.md new file mode 100644 index 0000000..b9912b4 --- /dev/null +++ b/09 Architecture.md @@ -0,0 +1,30 @@ + +# Architecture + +Supporting resources: + +1. [Lecture slides](https://drive.google.com/open?id=1Ux83hzw-DdcBWn6PUXz_xF3b-ytE4PsWLpSKS_dqBfw) +2. [Software Architecture Patterns (e-book)](https://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf) +3. [Building on Multimodal Databases (e-book)](http://info.marklogic.com/rs/371-XVQ-609/images/building-on-multi-model-databases.pdf) + +At this stage you have carried out Domain-Driven Design and now have a good idea about the system you are required to develop. + +In this lab you will be applying the knowledge from this week's lecture to the problem you have been given as your assignment. You should check Moodle and find out the topic you have been assigned. + +1. Use the information in this week's presentation to select three architectural styles that would be suitable for your scenario. +2. For each of these create a **Component Diagram** diagram showing how this could be applied: + 1. Analyse the system and agree on the architectural quanta. +3. Review your three designs and choose the best architecture (note that this might be combination of one or more of the styles you selected above). +4. Expand this architecture to include details such as: + 1. The quanta. + 2. The file/module structure. + 3. The use of in-process and/or out of process communication between the modules. + 4. The protocols you intend using to communicate between modules if out of process. + 5. Any third party libraries/modules you feel would help +5. Set up any code repositories you need in the `340CT-1819OCTJAN` organisation on the University GitHub server: + 1. Make sure the repositories are PRIVATE. + 2. Clone these onto your development machine. + 3. Configure your git details in each repository. + 4. Set up a suitable `.gitignore` file. + +Once everything is set up you are free to start developing your system. Over the next few weeks you will be introduced to a number of additional skills and techniques that you will be expected to apply to your project. diff --git a/10 Software Quality.md b/10 Software Quality.md new file mode 100644 index 0000000..2309b4f --- /dev/null +++ b/10 Software Quality.md @@ -0,0 +1,103 @@ + +# Software Quality + +In this lab you will be expected to set up a linter to ensure the quality of your code. The first part of the lab comprises a set of exercises to help you understand the tools and technologies. The last section contains instructions explaining how to apply this to your own project. + +Resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/1Os28FNScFv2lHLqDfXGMPpSNf-Zbx0ByEGa0Ft8vxhk/edit?usp=sharing) + +## 1 Using a Linter + +JavaScript is a powerful language and includes a number of powerful features but it also includes features that, whilst they may produce working code, will make your code difficult to read and debug! A **linter** is a program that analyses your scripts for _programmatic_ and _stylistic_ errors and will flag up anything that may cause problems. They define a _professional subset_ of the language and reject any code that doesn't meet that standard. + +There are a number of _linters_ available for the JavaScript language. The original one was written by Douglas Crockford (the author of JavaScript: The Good Parts). This enforced _his_ idea of good JavaScript and was notorously not configurable! There are now a number of popular linters available, your choice should be based on what will run in your IDE as well as your personal preferences. The most popular linters are: + +1. [JSLint](http://www.jslint.com/help.html), the original, by Douglas Crockford +2. [JSHint](http://jshint.com/docs/) +3. [ESLint](http://eslint.org) which is supported by many _IDEs_ and _code editors_ + +EsLint is highly configurable through a hidden config file that needs to be added to the project root directory. When you submit your coursework you must demonstrate that it contains no errors or warnings when run using an identical configuration file. + +### 1.1 The Linter Configuration + +ESLint is completely configurable through a configuration file `.eslintrc` which is located in the `01 Introduction to NodeJS` directory. By default any file or directory starting with the period (.) character is hidden. To display hidden files and directories click on the **gear icon** at the top of the _Documents Tree_ and choose _Show Hidden Files_. + +1. the **env** object imports groups of pre-defined global variables based on the _environment_ they are used in. In our example we will be writing scripts using the NodeJS environment so we want the linter to recognise any NodeJS global variables. +2. the **rules** object defines any additional rules we want to enforce. In this example we are specifying that we _don't want semicolons_ at the end of each line, that we will use a 2 space tab for indenting, we will use single quotes for strings and that we are using UNIX line endings. + +Near the bottom of the file list you should see a file called `.eslintrc`, the initial dot (.) in the filename caused it to be hidden by default. + +1. Notice that the file contents are using the _JSON_ format which should be familiar to you. +2. There are two JSON objects, **env** and **rules**. + 1. The **env** object describes the _environment_ you are using. In our example we indicate that we will be using the ECMA6 syntax, are writing _NodeJS_ code, and will be using _Jasmine_ tests. + 2. The **rules** object defines the rules we want to apply. As you can see we are requiring tab indentation, single quotes and avoiding the use of semicolons on each line. The full list of rules can be found in the [ESLint Documentation](http://eslint.org/docs/rules/). + 3. Each rule has a reporting level where 0 means _disabled_, 1 means _warning_ and 2 means _error_. This affects how the rule violations are reported. + 4. Some rules allow for additional options. If these are specified, both the reporting level and options need to be in an array. + +Whilst you need to use the supplied configuration file in your assignment you should take time to understand the range of [rules](http://eslint.org/docs/rules/) available and adding them to your `.eslintrc` configuration file. To make this process easier you can use this handy [ESLint Rule Generator](http://rapilabs.github.io/eslintrc-generator/). + +### 1.2 Running ESLint + +Although there are plugins for many popular IDEs you should get used to running the linter from the terminal. ESLint is available as a NodeJS package which allows you to run it from the terminal. Since you may find yourself using an editor with support baked in, why would you want to do this? + +1. Some editors don't have ESLint support. +2. Running ESLint in the Terminal gives a summary of the linting errors.to check if _all the scripts_ are fixed. +3. It can be configured to fix many of the most common error such as whitespace and semicolon usage. +4. The linting can be run as part of the _Continous Integration_ and _Continous Deployment_ process (more on this in a later worksheet) +5. Finally, it will be used during the marking of your assignment to make sure your code is formatted correctly! + +#### 1.2.1 Test Your Knowledge + +lets install, configure and run the console-based linter. + +1. Start by opening a terminal window and navigating to the `shopping/` directory. +2. Install the NodeJS ESLint package `npm install eslint --save-dev`. This installs it and adds it to your `package.json` file in the `devDependencies` section. +3. Run the executable `node_modules/.bin/eslint index.js`. This runs the `eslint` executable located in the hidden `.bin/` directory in the `node_modules/` directory. +4. You will see a list of all the errors and warnings found together with a summary with the total number of errors and the total number of warnings. +5. Open the `index.js` file and, using the linter report, fix the issues. You should re-run the linter regularly to check your progress. +6. Run the linter on the module using `node_modules/.bin/eslint modules/shopping.js` and note the errors it finds. +7. Now run the same command but this time pass the `fix` flag, `node_modules/.bin/eslint --fix modules/shopping.js` +8. Open the `shopping.js` file and notice that most of the issues have gone. The fix tool is not perfect, it may have introduced new errors so use it with caution! +9. Manually correct any errors until the linter reports 0 errors and warnings. +10. Finally run the linter against all the files in the project using `node_modules/.bin/eslint .` to ensure there are absolutely no linting errors in your code. Well done! + +## 2 The Assignment + +This week you are starting the development process. You are advised to use the `koa` framework rather than `express` or `restify`. Follow the steps listed below. You can find examples of all the files in the TEACHING-MATERIALS repository: + +1. Ensure you have private repo(s) in the 340CT-1819OCTJAN organisation (where the TEACHING-MATERIALS repo is found). Names should be in the format xxx-yyy where xxx is your university username. Clone this into your chosen IDE. +2. Create a `.gitignore` file in the root of your repository and add the files and directories you _don't_ want git to add to the repository. Use the example in this repository as a starting point. +3. Create a package.json file by running the `npm init` command. +4. Install any packages needed by your script using the `npm install --save xxx` command, where xxx is the package name. Make sure this has added the package to your `package.json` file. +5. Install any developer tools (such as eslint and jest) using the `npm install --save-dev xxx` command. This will add the module to the `dev-dependency` section of your `package.json` file. +6. Set up your `.eslintrc.json` file with the rules you want to use. +7. Add a `.eslintignore` file containing the files and directories you want to be ignored by the linter. +8. Add a jest section to your `package.json` that includes the coverage thresholds you are aiming for (100%). +9. Create a `pre-commit` hook: + 1. Create a `.githooks` directory in the root of your project. + 2. Create a `pre-commit` file in this new directory and add: + 1. A _shebang_. If you are on Windows this will be `#!C:/Program\ Files/Git/usr/bin/sh.exe`, on Mac or Linux it is `#!/bin/sh`. + 2. the line `echo "pre-commit hook working"`. + 3. Save the changes in the file and make sure it is executable. + 4. Set your hooksPath configuration variable to point to your new directory: `git config core.hooksPath .githooks` + 5. Stage and commit this new file using the git CLI. When you commit the changes yu should see the message `pre-commit hook working`, this indicates the hook is being triggered correctly. +10. Create a `README.md` file and add the name of your project. +11. Stage and commit the file using the terminal commands: + 1. You should see the message `pre-commit hook working` in the terminal. +12. Create a `pre-push` hook file and add a suitable message. Test it is working. +13. Start developing your code. Make sure you apply TDD (write a test to define your next piece of functionality before implementing). +14. Modify the `pre-commit` hook to run the linter. +15. Modify the `pre-push` hook to run the jest test suite with code coverage. + +### 2.1 Preparing for Test-Driven Development + +At this stage you can start building your system. Each time you commit code the linter will run. Each time you push your code it will run the unit tests. + +Every time you add a new `.js` file to your code you should: + +1. Create a matching test file using the format `xxx.test.js`. +2. Import the test frameworks and your js file into the test suite. +3. Run the test suites and check that it is picking up the new test suite. + +As you write the code, keep the test running going using watch mode. This means that every time you save a file the entire test suite will run. Keep an eye on the code coverage and make sure it **never drops below 100%**. diff --git a/11 Advanced Testing.md b/11 Advanced Testing.md new file mode 100644 index 0000000..d965787 --- /dev/null +++ b/11 Advanced Testing.md @@ -0,0 +1,100 @@ + +# Advanced Testing + +In this lab you will be refining your unit tests and augmenting these with the use of acceptance tests. The first part of this lab contains a number of exercises that cover the skills needed to complete the assignment. Make sure you take the time to complete the **Test Your Understanding** sections before applying these to your assignment. + +Resources: + +1. [Lecture slides](https://docs.google.com/presentation/d/1rY-Oc4LcSvguGyGSOz2NdOYo8-dtD0yUswmXfbi_-Ls/edit?usp=sharing) +2. [Test Cafe (an alternative acceptance testing tool)](http://devexpress.github.io/testcafe/) +3. [Test Cafe Studio (acceptance testing IDE)](https://testcafe-studio.devexpress.com/documentation/getting-started/) + +## 1 Defining API Fitness Functions + +It is important that we clearly define the interface that our API exposes. If this changes it can impact any code that makes use of it. This interface is defined in the routes file `index.js`. Up to this point however we have focussed our automated testing on the modules it imports. In this lab you will be learning how to write unit tests for the routes file. + +1. Locate the `exercises/05_advanced_testing/mocks/` directory and examine the `index.js` route file. Notice it has been created using the [Koa](https://koajs.com) web framework. +2. At the end of the file we export the koa `server` object, this allows us to import it into our test framework. +3. The `__tests__/` directory contains two test suites, one for the `todo.js` module (we have already seen this) and a second one, called `index.test.js` that will test our routes. Open this and study the code: + 1. At the top we import the [supertest](npmjs supertest) framework. This allows us to make HTTP api calls and check the response object. + 2. The tests are written in [jest](https://jestjs.io) and therefore follow the same structure as the unit tests you have previously written. + 3. Note that the sample code makes heavy use of [async functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) and so, if you are not familiar with them you should complete the **Async Code** lab exercises. + 4. There are two code styles you can use when writing the tests: + 1. The `get empty list` test demonstrates making the async http call, storing the results in a variable and then checking its content. + 2. The `retrieve a single item` test shows a chaining style. + +### 1.1 Test Your Understanding + +There is currently no delete functionality offered by the API. You will be expected to apply the principles of TDD to solve this: + +1. Locate the `todo.remove()` functionality in the module. Take a few moments to understand how this works. +2. Create a new route `DELETE /items:item` which will delete the specified resource. At this stage it should be empty. Create a `describe()` block in the test suite. +3. Complete the first TDD iteration: + 1. Write a test to add, then delete a single item, the status code should be `200` and the response body should return the item deleted using the same son structure as the other responses. + 2. Run the test suite, this new test will fail! + 3. Run the test suite with a watcher so that the tests run every time you save a file. + 4. Now implement the feature. As you save the code the tests will run. Keep working on this until all the tests pass. IS your linter picking up any coding errors? + 5. See if you can refactor the code to make it easier to follow. + 4. Complete the second TDD iteration by defining a tests that tries to delete an item that is not in the list, the status code should be `404` and the response body should contain the name of the item not found. + +## 2 Mocking + +In the previous example you were working with the `todo` module which saves and retrieved data stored on the hard drive of the server. Whether the data is persisted like this or in a database it always required the script to read and write from the hard drive which slows things down hugely. Because this is so sclow it makes all our tests run slowly, increasing the test suite run time and slowing us down. To solve this we will identify the module causing the slowdown and _mock__ it. + +1. Locate and open the `modules/todo.js` script. + 1. Notice that it imports the `node-persist` module and it is this module that reads and writes to and from the hard drive. + 2. Run the test suites, this will run the unit tests for both the `todo.js` module and the routes file `index.js`. Note the total runtime of these tests. + 3. This is the module that we need to mock. +2. Locate the `__mocks__` directory in the root directory of the project: + 1. Notice that this contains a file called `node-persist.x.js`. This is the mock module. As soon as we change the name to `node-persist.js` it will be used instead of the nom module of the same name. + 2. Notice that it exports exactly the same functions with the same signatures as used in the nam module. + 3. Change the name as indicated and run the tests again. + 4. Notice that several tests fail, this is because the mock has not been fully implemented. + +### 2.1 Mocking Tips + +Once the tests run with the live modules you can start to write the mock. Since there are so many tests running it can be helpful to isolate these. To run a single test you can use the `-t` flag as shown: + +```shell +node_modules/.bin/jest -t 'existing single item' +``` + +A usefule tip is how to use the debugger to debug your tests (and mocks). We will cover this in more detail in the next lecture. In brief: + +1. Open the chrome web browser and go the the url `chrome://inspect`. +2. Click on the _Open dedicated DevTools for Node_ link. This opens the chrome debugger and waits for the debugger to start. +3. Run the command `$ node --inspect node_modules/.bin/jest --runInBand -t 'remove item from list'` substituting the test you are trying to debug. +4. Use the Chrome Debugger to step through your code. + +### 2.2 Test Your Understanding + +1. Your first challenge is to finish writing the mock so that all the current tests pass. + 1. Run the test suite again, has there been any improvement in the execution time? +2. For an advanced challenge, note that the `index.js` routes file imports our `todo.js` module. +3. Locate the `modules/` directory and locate the `__mocks/` directory inside it. This is where you need to place any mocks for your custom modules. +4. The `__mocks__/todo.x.js` file is currently empty. + 1. Change the file name to trigger the mocking. + 2. Implement the mock so that all tests pass. +5. Run the entire test suite a final time and make a note of the time this took. Did mocking the `todo.js` module make a difference? + +## 3 Acceptance Testing + +### 3.1 Test Your Understanding + +## 4 Snapshot Testing + +### 4.1 Test Your Understanding + +## 5 Continuous Integration + +Its now time to implement the advanced techniques we have covered in this lab and incorporate the skills from the previous labs. By now you should have started to build your assignment. + +1. You are already writing tests for any modules you have been building and these tests should run every time save your work. Your pre-push hook should prevent you pushing the code if: + 1. Any of your tests fail. + 2. Your test suite is not providing 100% code coverage. +2. Note how long the entire test suite takes to run: +3. Study your code carefully and identify any modules that are reading from or writing to the hard drive. +4. Write mocks for these to speed up the testing process. +5. You have already started building the UI, whether a website or an app. +6. Create acceptance tests that validate this interface. +7. Once you have a working interface for some of the functionality try implementing **snapshot testing**. diff --git a/12 Profiling and Debugging.md b/12 Profiling and Debugging.md new file mode 100644 index 0000000..f5dfb64 --- /dev/null +++ b/12 Profiling and Debugging.md @@ -0,0 +1,88 @@ + +# Profiling and Documentation + +Resources: + +1. [Lecture slides](https://drive.google.com/open?id=1takMoPNZTk4IyfqrEssDm9yFfkQQxuA16ZBoohUso80) + +## 1 Profiling + +NodeJS includes the **Tick Profiler**, a native tool, which allows you to profile your NodeJS code. It is activated using the `--prof` flag, eg: + +```shell +$ node --prof index.js +``` + +This will capture data on the performance but, in a development environment this will need to be simulated using the [Apache Bench](https://httpd.apache.org/docs/2.4/programs/ab.html) tool, eg: + +```shell +$ ab -k -c 20 -n 250 "http://localhost:8080" +``` + +You will note that there are three flags used: + +1. `-k` - **KeepAlive** - perform multiple requests using the same session. +2. `-c 20` - **Concurrency**: the number of concurrent requests. +3. `-n 250` - **Requests**: the number of requests to perform in the session. + +Apache Bench generates a range of useful data however we need more information to highlight where the issues are in the code. This is done using a _tick file_. + +## The Tick File + +by using the `--prof` flag, NodeJS generates a _tick file_ in the current directory with the name `isolate-0xnnnnnnnnnnnn-v8.log`, where nnn... is a number. This file needs to be interpreted using a _tick interpreter_ and the analysis piped to a text file which can then be opened and read. + +```shell +$ node -prof-process isolate-0xnnnnnnnnnnnn-v8.log > processes.txt +``` + +## References + +https://nodejs.org/en/docs/guides/simple-profiling/ + +Using the profiling tool together with the [Apache Bench](https://httpd.apache.org/docs/2.4/programs/ab.html) server benchmarking tool. + +## 2 Debugging + +Node.js includes an out-of-process debugging utility accessible via a V8 Inspector and built-in debugging client. To use it, start Node.js with the inspect argument followed by the path to the script to debug; a prompt will be displayed indicating successful launch of the debugger: + +```shell +$ node inspect index.js + < Debugger listening on ws://127.0.0.1:9229/ea2bbf59-874e-45c0-9535-1553980dfec2 + < For help, see: https://nodejs.org/en/docs/inspector + < Debugger attached. +``` + +By default the debugger will stop on the first statement. It supports several commands: + +| cmd | action | +| :-: | ----------------------------------------------------------------------------------- | +| n | Step next (run the highlighted line and move to the next line but don't execute it) | +| s | Step in | +| o | Step out | +| c | Continue execution until next breakpoint | + +It is also possible to attach watchers to track values: + +- `watch(expr)` - Add expression to watch list +- `unwatch(expr)` - Remove expression from watch list +- `watchers` - List all watchers and their values (automatically listed on each breakpoint) + +### Using the Chrome DevTools + +The debugger can also connect to the Chrome Devtools. + +Open the `about:inspect` url in the chrome browser, this will open the devtools window as shown. Click on the + +![opening the Chrome DevTools](exercises/.images/devtools1.png) + +This will start monitoring websockets on two ports, we will be using port `9229`. + +![opening the Chrome DevTools](exercises/.images/devtools2.png) + +Start your script as before using the `node inspect index.js` command. + +## 3 Documentation + +### 3.1 JSDoc + +### 3.2 APIDoc diff --git a/13 Continuous Delivery.md b/13 Continuous Delivery.md new file mode 100644 index 0000000..70325e0 --- /dev/null +++ b/13 Continuous Delivery.md @@ -0,0 +1,100 @@ + + +# Continuous Delivery + +In this lab you will learn how to implement Continuous Delivery of your application using two different services: + +1. [GitLab](https://gitlab.com) provides an integrated CI/CD DevOps pipeline which makes use of Docker containers and is simple to configure. +2. [CodeShip](https://codeship.com) is example of Software as a Service (SaaS) and integrates with GitHub via an authentication token. + +Resources: + +1. [Lecture slides](https://drive.google.com/open?id=1b00JkdBlx05DjDrWKwZdJtzHbJR7Nstfw4_vUR9StBE) +2. [Starting and Scaling DevOps in the Enterprise (e-book)](https://page.gitlab.com/rs/194-VVC-221/images/Starting%20and%20Scaling%20DevOps%20in%20the%20Enterprise.pdf) +3. [Simple authentication API](https://gitlab.com/covcom/authentication) + +Feel free to make use of the simple authentication API in your assignment, this will allow you to focus on building the core functionality. Be aware you will need to modify it to get it to integrate into the rest of your project. + +## CodeShip CI + +The first step you need to take is to authenticate CodeShip by creating an access token. From the top right menu choose settings: + +![GitHub settings](exercises/.images/codeship01.png) + +Choose **Developer settings** from the left sidebar and then choose **Personal access tokens**. + +Choose **Generate new token**. You will need to choose the following permissions: + +1. admin:public_key +2. admin:repo_hook +3. repo + +![Token permissions](exercises/.images/codeship02.png) + +Call the new token **CodeShip** and generate the token. You will then need to copy this to the clipboard. + +Log into CodeShip and locate the **Connected services** option from the settings menu. + +![Token permissions](exercises/.images/codeship03.png) + +Switch on the GitHub enterprise option and enter the following details, substituting your university username and your access token. + +![Token permissions](exercises/.images/codeship04.png) + +## Adding a New Project + +You should now access the **Projects** menu in CodeShip and choose **New Project**. Make sure you choose the **GitHub Enterprise** link and not the GitHub icon! + +![Token permissions](exercises/.images/codeship05.png) + +Paste in the GitHub url where requested and, on the next screen select **Basic project**. + +On the **Configure your tests** screen choose **NodeJS** from the dropdown list and delete all the commands from the list except `npm install`. + +-------- + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. This lab will include your third sprint and will bring together many of the topics already covered. + +There is an example repository on [GitLab](https://gitlab.com/covcom/continuous-integration-example) + +## 1 Configuring Continuous Delivery + +In the previous sprint you used the **Pull Request** mechanism to integrate code into the master branch. In this sprint you will _replace_ this with the process of _Continuous Integration_. These two approaches are non-complimentary and each has its pros and cons. By the end of this sprint you will have a good understanding of these. + +Your team should already have a suite of tests for both _functional_ and _non-functional_ requirements for each component in your project and, in this lab, you will be using these to build a **Continuous Delivery Pipeline** using the tools integrated into _GitLab_. + +The restrictions are that you can only use tests that return either pass or fail and have a non-zero code on failure. This should include: + +1. Linters. +2. Unit tests. +3. Module dependency tests. +4. Code duplication checks. +5. Code coverage checks (if there is an option to specify thresholds). + +You will need to create a `.gitlab-ci.yml` file in the root directory of your project which will be detected by GitLab and run each time you push your code. These are lots of examples available for you to learn from, both in the `exercises/08_ci/` directory and online. Make sure the _CI Pipeline_ is correctly configured by pushing both good and bad code before starting your third sprint. + +You will also need to configure GitLab to only allow merging if all tests have passed. In this way you can bypass the requirement for the code to be reviewed by the Scrum Master which should speed up the process of integrating code into the Master branch. + +### 1.1 Examples + +To help you configure your GitLab CI pipeline there are a couple of sample repositories you should be studying which cover most of the platforms you are developing for: + +[ci-nodejs](https://gitlab.com/covcom/continuous-integration-example) shows how to build a CI and CD pipeline for a NodeJS API. + +## 2 Development Process + +1. Create a local feature branch if the task is new and push to remote. +2. Rest of team pull the branch and switch to it then run existing test suites. +3. Write **unit tests** and **integration tests** to define new functionality. +4. Now code should be written to pass the tests making sure all the **non-functional tests** such as the _linter_ and _code duplication checker_ still pass. +5. Once local tests pass: + 1. code should be pushed to remote (triggering CI tests). + 2. Code changes should be pulled from the master branch. +6. Now the branch can be merged into the master branch: + 1. Create a pull request on GitLab. + 2. If all the tests have passed on both branches you can merge the code. + 3. Delete the feature branch if the feature is complete. + +## Jenkins + +Docker Hub contains a complete [Jenkins image](https://hub.docker.com/r/jenkins/jenkins/) which you can deploy to a heroku instance. diff --git a/exercises/.images/codeship01.png b/exercises/.images/codeship01.png new file mode 100644 index 0000000..81f1967 Binary files /dev/null and b/exercises/.images/codeship01.png differ diff --git a/exercises/.images/codeship02.png b/exercises/.images/codeship02.png new file mode 100644 index 0000000..ee925e9 Binary files /dev/null and b/exercises/.images/codeship02.png differ diff --git a/exercises/.images/codeship03.png b/exercises/.images/codeship03.png new file mode 100644 index 0000000..a810253 Binary files /dev/null and b/exercises/.images/codeship03.png differ diff --git a/exercises/.images/codeship04.png b/exercises/.images/codeship04.png new file mode 100644 index 0000000..8db6e7a Binary files /dev/null and b/exercises/.images/codeship04.png differ diff --git a/exercises/.images/codeship05.png b/exercises/.images/codeship05.png new file mode 100644 index 0000000..3ba7bc1 Binary files /dev/null and b/exercises/.images/codeship05.png differ diff --git a/exercises/.images/devtools1.png b/exercises/.images/devtools1.png new file mode 100644 index 0000000..d39af9d Binary files /dev/null and b/exercises/.images/devtools1.png differ diff --git a/exercises/.images/devtools2.png b/exercises/.images/devtools2.png new file mode 100644 index 0000000..9590345 Binary files /dev/null and b/exercises/.images/devtools2.png differ