Previously on...
I finished up my previous series about how I started to explore the consultant side of the IT sector.
This blog post starts a new series. Below you can find a bullet list of what is used in this project. The topics on which I'll be blogging are DevOps, Analyses, Development, Acceptance Environments, Documentation and Knowledge sharing. This way, I have some structure on what I can write about next.
Through this, I want to inspire others or have discussions about why other approaches can be more beneficial.
Context
I help deliver a project that will enable a user to signup into the customer portal using a registration system. The customer asked me to develop two Web App services that are functioning as REST APIs.
When a user signs up, he will have two options:
using Auth0 and ItsMe, so the user can be verified using the ItsMe app
using personal data with verification sent by sms or email.
Technology used
DevOps
I do not have access to create pipelines and resources in Azure DevOps. However, I do function as a lead for my services so I do work closely with the DevOps persons when problems arise or information is needed.
All services make use of continuous integration as well as continuous development. The customer describes what branching strategy I should use.
The entire solution is deployed using Web App ASE on Azure.
Analysis
This has already been done by the enterprise architect and the business analyst. What I did was help with:
Clarifications and documents to reflect what is development
Challenging content of access tokens
Challenging REST-call signatures
Development
The setup of the solution consists of a service-oriented architecture. With some good faith, you can see some resemblance with the microservice-oriented architecture.
Acceptance Environments
The business analyst will validate the services using SoapUI and PostMan. Whenever an error occurs, extra system tests and/or unit tests are written.
Documentation
The analysis needs to reflect what is going to be developed, as well as what is developed. However, I make it my mission to put as much of the documentation in swagger.
Each week, there is one hour that the .Net developers on the project meet to exchange strange issues, nice discoveries and so on.
Using the 4 eyes principle, we can help out each other.
When there is some discussion where the customer does want to have some answer, I do talk to my XPirit colleagues about it. After having the discussion, I write a concise email to the customer with the problem and how we recommend approaching this.
Outro
With this post, I have mentioned a lot of technologies, architectures, and ways of working that I will explain more about in the next posts. Let me know what topic you want to know more off in this context.
