Skip to content

Commit

Permalink
Merge pull request #248 from jlndk/hjda/4.4
Browse files Browse the repository at this point in the history
4.4 Devops Style
  • Loading branch information
Hjaltesorgenfrei authored May 11, 2020
2 parents 36a0c22 + e66a635 commit 5b25770
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 2 deletions.
3 changes: 2 additions & 1 deletion report/43_Lessons-Maintaince.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
## Maintenance
### Maintenance

To facilitate maintenance of the MiniTwit system multiple CI tools were utilized. These tools verify that the system was still in working order after changes to the code base. They include running unit tests, verifying API simulator still works, getting analysis from SonarCloud and metrics from Google's Lighthouse.
The last of which, Lighthouse, showed there was an issue when merging a specific pull request to master.
But due to this issue not getting spotted, combined with misconfiguration of which CI checks had to pass before code could be merged with master, the register page on the website ended up breaking. This was first realized when a user reported the error.
Expand Down
9 changes: 8 additions & 1 deletion report/44_Lessons-DevOps-Style.md
Original file line number Diff line number Diff line change
@@ -1 +1,8 @@
Reflect on and describe the 'devops' style of your work. What did you do differently to previous development projects, and how did it work?
### DevOps Style

Following DevOps practices had a significant impact on how implementations were handled in this project. When doing a project just from a developer's perspective, it is much easier to not think about ease of operation and maintenance, but by doing it with a DevOps perspective it is clear how large part it is in a production system.

It makes the value in reproducibility very apparent, as you never know when you come back to a system that has not been touched for ten years. By having everything centralized to a single location, like a git repo, and configuration and dependencies explicitly defined in code, it makes it easy to spin up a instance many years later.
By having unit and systems test it also possible to verify that the system is in working order. Both after many years or just after changes are made.

Having a focus on automation whenever possible decreases the overhead for developers. They don't have to worry about verifying to as large of a degree and deployment is a non issue. This decreases lead time for fixing issues and implementing features, and therefore increases customer value. It should also increase the effectiveness of developers as they can focus more on their job and worry less.

0 comments on commit 5b25770

Please sign in to comment.