Process Optimization & Efficiency
We strive to refine and optimize our development processes as much as we can. This section will outline the methodologies, tools, and practices we employ to achieve thes objectives, including the intrgrations od CI/CD practices and application of DORA metrics via Grafana.
We adopted a more flexible, non-traditional Agile approach, focusing on flexibility and continuous improvement within the team:
- Weekly Meetings: Due to heavy time constraints, and difficulty finding time slots, we settled on holding a single, focused two-hour weekly meeting instead of daily stand-ups. This allowed everyone to participate without making it a burden on their schedule. These meetings serve to update, synchronize efforts, plan for the upcoming week, and discuss any immediate issues we are facing.
- Feature-Driven Tasks: We structure our work around building features which worked well enough considering our time constraints, interests, and the module commitments.
- Pair Programming: We encourage pair programming when it is feasible, since it helps to share knowledge and make the development process faster, especially when dealing with complex issues or bugs.
- Task Flexibility: Tasks are assigned with a consideration of individual interest, availability, and capacity, allowing team members to contribute effectively without causing burdens to their academic obligations.
- Handling Changes: When new information or unexpected situations arise, we discuss these developments in depth during our meetings or via Slack to decide on the best course of action. This helps us change or adjust our plans quickly to accommodate new insights or requirements.
- Integrated Development Environment (IDE): Team members are free to choose their preferred IDEs, with most opting for Visual Studio Code.
- Version Control: GitHub serves as our version control, where we also do code reviews and collaborate.
- Automation through Workflow Scripts: We use GitHub Actions for automating repetitive tasks such as testing and linting.
- Weekly Review Sessions: At the start of each weekly meeting, we go from teammate to teammate, where each team member shares their progress over the past week. This session acts like a small stand-up meeting, where everyone can share insights into their task, accomplishments, and challenges.
- Pull Requests (PRs): PR reviews are integral and mandatory to our workflow, which allow feedback and collaborative decision making while making code changes.
- Distributed Responsibilities: Documentation tasks are shared among team members, as to not overwhelm a single person. There are specific individuals responsible for user guides, collaboration practices, and technical documentation.
- Accessible Repository: All documentation is hosted on GitHub, so it is always accessible and maintained alongside our codebase.
- Communication: Our primary communication tool is Slack, with a dedicated channel for the project.
- Weekly Meetings: Regular scheduled meetings allow all team members to be kept up-to-date with the ongoing development progress and have support for their individual tasks.
- Collaborative Meetups: Outside of our scheduled meetings, team members frequently gather to work on tasks, even those not directly shared. These meetups helped create a collaborative environment, where ideas could be shared freely, problems solved together, and support is readily available.
- Open PR Management: Ongoing challenges with open pull requests are addressed through review rotations and code ownership incentives.
- Branch Management: Policies for branch creation and deletion have being refined to minimize the clutter and maintain a clean, efficient repository.
In order to enhance visibility into our development and deployment effectiveness, we integrated Grafana to track DevOps Research and Assessment (DORA) metrics. This implementation serves as a tool to assess our performance.
Open the Grafana Dashboard Link which should redirect you to our login page. In order to view the dashboard itself you need to be a part of the organization. In case you do not have and require access, please reach out to me.
Once you are logged in you should have an overview over the whole dashboard. In case some variables are incorrectly loading you can fix it by inserting the following data:
- datasource: code-idp-data
- Organization: codeuniversity
- Repository: code-idp
- Labels: (null)
- Branch: main
- Milestone: (null)
-
Toggles: all of the 3 toggles on the bottom on.
Grafana defaults to now-7d when viewing dashboards. If you want the full overview of the entire priject's lifespan you can adjust it as follows:
- Click on the timeframe button located on the upper right region and choose your preferred viewing timeframe.
- Select
1st Februarytillnowto have a full overview of the project.
Our Grafana dashboard is designed to provide a clear visual representation of various key performances that help us monitor and improve our project workflows. Here's a breakdown of all of the metrics displayed on our dashboard:
-
Success and Failure Rates: Tracks the success and failure percentages of deployments, helping us understand the reliability of our deployment processes.
-
code-idp Deployment Successes: Indicates successful deployment attempts of the
code-idprepository. -
idp-hosted-projects Deployment Successes: Shows the deployment success rate for the
idp-hosted-projectsrepository.
-
code-idp Deployment Successes: Indicates successful deployment attempts of the
-
Total and Average Run Duration: Provides insights into the operational efficiency.
- Total Run Duration: The total time taken for all runs to complete.
- Longest and Shortest Run Duration: Highlights the runs that took the longest and shortest times, showcasing the variability in run times.
-
Pull Request Timeline: Shows the frequency and timing of pull requests, which helps us track team activity and bottlenecks in code review processes. Note: The timeline is flipped here.
- Pull Requests Created: Number of pull requests made over time.
- Active Pull Requests: Currently open pull requests and how long they have been active.
- PR Average Open Time: Average duration that pull requests remain open, an indicator of our review efficiency.
These metrics that are set in place, but not being actively tracked, as we did not use them:
- Releases
- Tags
-
Issues Created and Closed: Monitors how quickly our issues are being addressed and resolved within the project.
- Issues Created: Total number of issues reported.
- Active Issues: Current open issues and their duration.
- Issues Average Open Time: Average time taken to close issues, helping identify delays.
These metrics that are set in place, but not being actively tracked, as we did not use them:
-
Issues Creates in Milestones
-
Issue Tracking: Number of issues created, current active issues, average time to close, and tracking within milestones.
This tab is located at the bottom of the dashboard and is desiged to provide the comprehensive dataset that is being fed into the dashboard, in case you we ever need more details when making data-driven decisions.
- Complete Data Visibility: The entire view of the data is visible, allowing you to cross-reference and conduct comprehensive audits.
- Custom Queries and Reports: Custom queries and filters are possible here to extract specific information which helps in personalized analysis.
- Historical Analysis: You can trace back to any point throughout the project's history to understand specific trends, paterns, and how the project evolved in its lifetime.
The dashboard is structured to make it easy for everyone to understand:
- Separated Sections: Each metric type is visually separated for quick reference.
- Interactive Elements: Users can hover over the charts to get more detailed information or filter data based on specific criteria.
The application of standardized naming convention for branches and commits, including the later introduced Git hooks, and enhancements to our PR process have been a great aid in reducing inefficiencies and boosting the quality of code integrity. These introduced measures have lowered mismanagement of branches, decreased the amount of errors while improving the overall code quality as well and team accountability and ownership of their own code.
Despite Grafana's amazing potential, its difficult UI and initial delay in implementation have posed several challenges, resulting in some shortcuts being taken.
- Visual Optimisation: Despite the dashboard being quite clear, there's a lot of room for improvement, with things such as the timelines being reversed, or making the visuals color coded.
- Self Hosting Grafana: Currently we are using Grafana's self-hosted cloud service, which comes with limitations. For the future, we should look into hosting our own dashboard.
- Seperate Database: The data we are recieving from GitHub is sourced through a GitHub token. This requires a constant GitHub key to be available that comes with security risk, but it also created a data manipulation limitation. Ideally, we should utilize InfluxDB for the future database.
- Observing Over a Long Period: Ideally Grafana should have been implemented at the early stage of the project. If the above mentioned issues are addressed, the dashboard should be kept online over a course of several months data over a longer course of time can be collected and analysed.