Project Assignment – 2DV611

This text will describe the project assignment for the course 2DV611 at Linnaeus University, Kalmar, Sweden.

A deployment pipeline

The assignment is a group project where you should develop a deployment pipeline supporting a continuous delivery workflow of an open source web application. Which web application you will use is up to the group to decide based upon the work you did in the reports.

The deployment pipeline should be build for a developer team to continuously develop and maintain a web application. The goals are

• To explore different possibilities for the pipeline (single pipeline, pipeline for components, etc.)
• To experiment deploying in several environments with different purposes and smoke tests
• To experiment with zero downtime releases and rollback deployments to a previous version
• To achieve a delivery process where a new developer can continue the development of the application in a transparent, easy and quality way.

This assignment has several parts and learning objectives:

• Getting the understanding for producing deployment pipelines, including CI-servers, artifact repositories and so on.
• Understand how to implement automated testing of software and application in the deployment pipeline.
• Working in group with a real software project with some bigger code base and test suits.
• Automate the deployment in different environments maximizing the feedback speed of errors/bugs and the confidence in the code
• Getting the code changes all the way to production
• Your web application should be running in a production environment as a last step of the deployment pipeline.

We will not specify a long list of functional requirement. At this level you should be able to think about the problem and identify wanted features by your self. By reading the literature and article you will get the understanding of the parts implemented in a good deployment pipeline and how to bring your software and code changes to production in a fast, confident and secure way.
We are aiming for Continuous Improvement!

As a individual project member

To get a better understanding of a more complex software, all project members must be active throughout the development. Every member of the team should do a lot of commits and you should use the idea behind continuous integration to get the experience needed. You should use some kind of ticket/issue system that will allow you to plan your work and for the examiner to view the individual work in the group.

Iterative meetings – Supervisor meetings

During the project the groups will have meetings and discussions with the course management and the rest of groups.

During this meetings you should describe what you have done during the week, how you have separated the work, what you have tried that worked, what you have tried that did not work as expected with the effort that you could afford and how you will work until the next meeting. Try to keep these meetings effective and be prepared to guide the examiner through your progress. The help that you can give to issues from other groups will be positively considered.

Some meeting have pre-defined topics that should be prepared in advanced:

* Meeting 1 – The group should have decided on a open source application.
* Meeting 2 – Presentation of the pipeline to construct and the plan to achieve it. Presentation of the first steps already taken within the plan (e.g., the application builds and it can be deployed in the production environment [semi-]automatically).
* Meeting 3 – A running pipeline
* Meeting 4 and beyond – Optimizing… (zero downtime, components, advanced data management, smoke tests and feedback from them, advanced rollback, etc.)

See below for more info about the meetings

Examination

The examination is divided into the following parts::

• Group project
• The artifact of the group work, should be provided in the Github group repository along with documentation.
• A documentation for a new developer.
• The group should provide a documentation for a new developer that will start working on the software.
• Be sure to describe the underling process for each step, where the developer can find information. What will happened when errors occur, where to visually view the result and so on.
• All the report submissions will be through myMoodle platform

Individual report from the group work

Since the grade is individual you have the chance to reflect over your (and the groups) work in a personal report. It will only be read by the examiners. The goal of the report is to show your involvement and understanding of the project along with a more detailed view of what you have done and how much time you have spend on the assignment. The following part should (at least) be part of the report. Feel free to add own headlines.

• Your work
• What have been your focus in the project
• Personal reflection of the project
• What is good, what is bad
• How have the group worked together
• What have you learn during this assignment
• What advanced characteristics for a deployment pipeline you have started exploring but you could not fully develop them in your project due to time constrains
• Points to your team members considering their contribution to the project. You have 20 points to distribute among all the member of your team (including yourself).
• Optional: Comment/proposal to improve the course

Grading matrix

The final grade (A-F) is a grade based on all the above examination assignments.

A – For an excellent performance – the students have a very good knowledge of the subject and can discuss about the oral questions on a high level. The student have solved the assignments before the deadline and presented artifacts showing he/she have a high level of understanding for all aspects of the relevant material.

C – For a good performance – the students have a good knowledge of the subject and can discuss about the oral questions in a good way. The student have solved the assignments before the deadline and presented artifacts showing he/she have a good level of understanding for all aspects of the relevant material.

E – For a performance meeting only the minimum requirements for acceptance on each examination steps.

Fx – For a performance which does not meet minimum requirements for acceptance on each examination steps.

F – For a performance which is unacceptable in all respects.