frankbecker
commented
3 years ago Here are some of the steps I would take in order to maintain this repository. I already have implemented some of these ideas, wit this code challenge. This project is fully integrated with GitHub and it's offerings.
A Kanban board would have to be created, this board would have three columns, Ready, In Progress, and Done. Developers would create branches tagged with the story number, and every commit should include the story number as well. This way we can trace the stories down to the code. We can create commit hooks which can enforce story numbers to be part of the commit message.
I would set up and enforce commit hooks, these commit hooks would create checks and balances, making sure the code is ready to be committed and pushed. A few examples of commit hooks are:
- Story number is included in the commit message
- Unit testing threshold is met and tests are successful
- Code Linting is executed
CI/CD would be triggered by a push to a feature branch. The pipeline would execute many steps, including Linting, Unit Testing, and E2E tests. Once all tests and steps have passed, a Pull Request can be created, if the feature branch build fails, the Pull Request will not be allowed to be merged into the main branch, this would all be automated. A Pull Request will require at least 2 approvals before it can be merged in, this obviously depends on the size of the team. Once Pull Request is merged, the feature branch is deleted and the main branch build will execute, and it will run all the needed steps in order to get a build ready for production. Every build will tag the repository, this will ensure that we can easily checkout a tag for a particular build. Once the main branch build steps are complete, the build is then deployed to a QA environment where developers and business partners can test. The git branching model will be followed, this will allow for feature and release branches and tagging.
If this repository is maintained by a team, we will use Agile Scrum, and all Scrum ceremonies will be followed, such as:
- Sprints are to be 2 weeks long
- There will be a closure at the end of every sprint, and the team will demo
- There will be a retro and planning, in order to kick off the new sprint
- Stand ups happen every day, no more than 30 minutes long
- Back log refinement, will happen once a week, stories are groomed and sized
- Stories will be assigned to meet the team's capacity and velocity
These are some of the fundamental things that come to mind. I believe these steps are necessary for a successful Software Engineering team, and product.
Please use your experience in order to demonstrate how you would be a maintainer of that repository