Developing and Deployment of Enterprise Software as a Professional

Introduction

(From Canvas)

Enterprise software is used in the context of companies which use large-scale distributed software, with many types of users, and substantial amounts of data.

In such a context, you will develop software and software related products (for instance software design, test setups). All of this should be transferable to the current stakeholders, and software engineers who work on the software after you leave.

Together with your team you agree upon a way of working that is considered professional in a large IT software organization. This software development process should be agile to accommodate future changes (for instance scrum).

Your behavior supports the chosen way of working. You consistently share technical knowledge and experiences of the software development process both inside and outside the team.

Besides requirements needed by direct stakeholders, you also take other viewpoints into account which are relevant (for instance GDPR, ethical & legal issues).It is your job that all your results can be verified, validated,and transferred to others

Learning focuses

In order to shape the upcoming curriculum, I’ve chosen various learning focuses for Developing and Deployment of Enterprise Software (as a Professional). These are work in progress, and have to be developed out further.

Category

In the tables below the category tab depicts the nature of the skill concerning the listed task.
Additionally to the standard, I’ve expanded with a custom table with tasks I came up with.

  • T = Technical skills

  • N = Non-technical skills

  • R = Research & development skills

  • P = Professional skills

Learning tasks

Task#

Category

Requirement

Status

Description

#0

T

Should

Done

Project context

#1

T

Must

Done

Examples of contribution to the group

#2

T

Should

Done

Ethical & GDPR

#3

T

Must

Done

Peer review

Proftaak contributies

  • DOT framework research into Ci/CD

In which I spearheaded a research into a suitable Ci/Cd for our customer. In order to do this, we set up various different requirements and ultimately presented it to the customer – asking for advice, and then building and iterating further on this.
https://i.imgur.com/V9qp7OH.png

  • Project lead (1-2 sprint)

https://i.imgur.com/LYSgwDW.png
I took project lead for the first two sprints of this semester, in which I set up scrum-poker; and helped guide the team with creating teams, tasks, etc.

  • (MVP #1) CI/CD implementation, configuration & management

https://i.imgur.com/1OxA17o.png
Having some experience in this from previous semesters, I set up the CI/CD pipeline using Jenkins, Sonar initially and then through the semester implemented Docker publishing & assisted with the rollout to automatic rollout to Rancher. As I was learning more about new DevOp tools (such as Grafana) I took steps to implement these into our environment.

  • Set up meetings, presentations, agile/scrum methodologies

  • Communication with PO/share-stake holders, setting up sprint goals etc.

  • Scaling project: Setting up communication layers (e.g. RabbitMQ, Rancher in cluster)

https://i.imgur.com/NIZmldg.png
As we were doing this and learning about statefulness & stateless I took initiative starting very early in the sprints that major refactoring was going to be required. I took steps in informing all the parties that this was very important; as it was vital to the success of the project. Our focus was put first on setting up a CI/CD and Android application; which is why I raised this concern. Ultimately I took steps in creating small teams within our team to prepare for making the entire stack stateless.

  • (Assisted) Changing the Python code to allow for MongoDB persistence

  • Clustering: Setting up the entire Kubernetes cluster so that it could be run in the cloud

I was confronted with several issues as we set up our cluster, namely about the security in RabbitMQ. The college infra shut down our VM twice during the semester, both times because our RabbitMQ was running on a default port (first time with default creds, which was justifiable). The second time however, we had put auth into this container but during debugging one of my teammates put it back on its default port, causing it to get shut down again. Together with another cyber student we performed an autopsy on the server and we found malicious software the first time that was promptly removed by me and a second time we saw no traces of an intruder. This has caused to some (passionate) debates between myself and my teammates, in which I have recommended the implementation of a more secure firewall many times but was ultimately rejected as a team decision. Our PO was ultimately unmoved by anything related to (infra) security, so my advice fell on deaf ears and I have not raised an issue over this ever since.

  • Android: (Attempted to) create a Bluetooth Low Energy (BLE) PoC in Kotlin Jetpack Compose, used multiple frameworks to try and build a proof of concept for this implementation.

When the BLE implementation did not end up succeeding in a timely fashion, I took initiative to discuss this with the PO & stakeholder(s) and to re-evaluate if we were the right team for this type of implementation. We ultimately agreed that a documentation handover would instead have to be created so that another time can iterate further on our work.

  • Load balancing: after our stateless deployment, I took steps in working together with the entire team to set up a load balancing test.

In order to complete our load balance test I had to work together closely with the refactoring team, and I found myself very often debugging with them in order to advance the migration to statelessness. After a long and arduous road, we finally were able to effectively do a load balance test and see the load being shared to multiple containers of the same pod. I consider myself a vital part in being successful with this.

Knowledge sharing

During the various sprints, I took initiative in trying to explain to the rest of the team how the inner workings of the deliverables worked that I participated in. One of those, for example, is the CI/CD pipeline. Together with another team mate we’ve given multiple workshops to other members in the team explaining how the entire process looked like and how they could use it.
Ultimately, this didn’t help them very much – at least, that is my own observation. My theory behind this is that this knowledge that I tried sharing initially clashed with team members because of external & internal motivation. Where external motivation is akin to someone telling you to do something (causing you to not want to do that thing). Versus internal motivation, in which someone identifies that they need to do it. This became noticeable to me when the members working in the refactoring team required more knowledge over the CI/CD during debugging. So when they needed to know that information (internal) instead of me telling them how to (external) it became much easier to guide them. But, what is important to keep in mind is that they were able to ask me questions about the Ci/CD partially because of these workshops that have been given by me and another Ci/CD teammate.
Outside of this, I was the first to use JMeter in my team, a load balancing testing tool; and I’ve explained to four different members how it works and how they can use it in their own projects. I’ve helped them set it up, and use it and understand and comprehend what the statistics mean. There are many other smaller tools like this, but not worth mentioning.

Peer feedback (14/06/2022, anonymous):

Tip voor mijzelf: Betrek passievere mensen wat meer.
Top voor mijzelf: Ik neem alsnog vaak initiatief ook al is het niet mijn verantwoordelijkheid.
Tip: Veel theoretische kennis maar soms niet relevant voor de proftaak
Top: Vaker op tijd gekomen
Tip: Veel theoretische kennis maar minder goed terug te zien in praktijk. Meer implementeren want je kant het :)
Top: Neemt een goede leidinggevende rol en probeerd structuur binnen het project te brengen, stelt goeie vragen en kan goed met en kritische houding naar het project kijken.
Tip: Geef andere in de groep meer kans om te spreken.
Top: Zorgt altijd dat het project in goede banen loopt.
Tip: misschien iets minder initiatief nemen, maar dat heeft Onur al gedaan de laatste sprint
Top: heeft altijd heel erg het initiatief genomen
Tip: (blank)
Top: je neemt automatisch de leiding, en probeert mensen ook goed bij te sturen als ze afgeleid raken
Tip: geen tips eerlijk gezegd. Erg tevreden met het werk wat wordt geleverd
Top: krijgt altijd alles af, erg veel kennis, en helpt ook anderen binnen de groep

Peer feedback (25/02/2022, anonymous):

Tip: probeer iets meer dingen die je doet qua devops uit te leggen, af en toe lijkt het heel erg alsof je magische dingen aan het doen bent waar de rest niet heel veel van snapt’
Top: je neemt vaak de leiding in groepsgerelateerde opdrachten, en brengt vaak mensen weer bij de les wanneer ze afgeleid raken.
Tip: Probeer theory te backen met praktische oplossing en ideeen.
Top: Theoretisch heel goed en vraagt goeie vragen en zorgt voor out of the box ideeen.
Tip : geen
Top: Gekregen taken altijd af en goede samenwerking en sociaal. Altijd bereid om te helpen.
Tip: Heb er geen
Top: Neemt initatief, kalm en doet goed mee. Ook veel CI/CD verstand
Tip: vaker optijd zijn.
Top: veel kennis, neemt vaak de leiding, en heeft een sterke mening
Tip: Discussies kunnen soms te ver gaan of te lang duren.
Top: Denkt altijd goed na over keuzes en stimuleert discussies.