powered by SD Software-Design GmbH
You can find this project on GitHub, but we actively develop it on GitLab.
🌐 Website 📖 Wiki 📑 Issues 📖 Documentation ✏️ Contributing
Our "DevOps Customer View" is a simple web portal that collects information from DevOps tools like GitHub and GitLab (more to follow) and provides a quick overview of progress, status, tickets, and milestones as well as the documentation for projects managed within these tools.
DevOps tools are (obviously) built for developers, engineers, product owners, admins, or other people working in "tech". Often they are too complex and powerful for "non-techies" to understand and work with. They often do not provide views or interfaces for customers as they are not the intended target audience - but they are loved by developers for their comprehensive features.
Note: Some DevOps tools provide features like the GitLab Service Desk but they are very limited in functionality
Management tools that project managers, business economists, sales teams, or customers/consumers prefer are more focused on visualizing information, progress, relations, numbers, and charts. Details of technical processes, the implementation, or the actual work that is done in the hidden usually cannot be fully represented.
When the management or the customers require developers to use these tools in order to be able to view and interact with the progress and processes this often means that they have to maintain or track information with different tools or transfer information.
The other way round explaining to customers or managers how to properly use DevOp tools can be challenging.
⚽ Our goal is to allow developers to continue using their most beloved DevOps tools and generated a simple interface that provides customers and other people with no technical perspective on the project with information on the progress.
Given a Project ID and an Acces Token this UI provides authenticated users a couple of views and functions to view and create tickets (issues) and track the current project status (using GitLab, GitHub following soon). Furthermore, it provides readable access to the time tracking feature of those tools and the project documentation hosted inside the corresponding wiki. The Web interface itself is designed to store as little information as possible inside its own database but uses APIs and caching infrastructure to provide the information given.
Follow the Django Setup Guide to prepare your environment. We recommend using a virtual environment to install the dependencies from our requirements.txt.
After installing Django do the migrations and remove the .example ending from your main/local.py.example and adjust the settings according to your needs. If you need to change other settings copy the corresponding section from main/settings.py to your local.py instead of manipulating the settings.py itself.
You may change the CACHE setting to use Redis, Memcached, or any other caching backend. By default the database cache is activated - you need to run python manage.py createcachetable to create and use the caching table if you want to stay with database caching.
- Create a superuser, start your server and log in to the Django admin panel.
- Add a
Userwith a valid email address using the Django admin panel. - Create a new
Projectand assign it to the user. Add the project ID - for GitLab you find the ID within the "Settings > General" section. - Create a project access token (GitLab Help). See additional notes below.
- Create an
UserProjectAssignmentand chose the already createdUserandProject. Add the access token created in step 4. - Save and log in by entering the email address and password of your user.
If you are on a trial plan or any tier below "Premium" you may have to use the personal access token instead.
Please note that the name of the access token is used and shown as author/editor in comments or logs. So if you create a project's access it should have your customer's/manager's name.
Assign the role "reporter" to your access token and allow access to "api". No other permissions are needed.
Please do not add custom themes/designs/templates to this repository!
Create your own repo and add your own base.html (you might want to copy and modify or preferably extend /userinterface/templates/base/base.html).
Go to the project root of your Twayn instance and load your custom theme as a submodule with git submodule add -f {url} ./DevOpsCustomerView/userinterface/templates/{theme-name}.
Go to local.py and change the name of the active theme to the {theme-name}.
Whenever you want to overwrite a template or a block inside a template create a file with the same name inside your theme. Extend the original file from the base template and overwrite the blocks you want to change inside it.
Whenever a template file is not present in your individual theme the default from the base theme is being used.
See an example below:
This project is maintained by the SD Software-Design GmbH - a software development company based in Freiburg, Germany. Any other authors, contributors, and volunteers are welcome.
This software is provided and maintained under the MIT License. We kindly ask you to send merge requests to our public repo in case you are adding features to your invdividual copy of this software.
We are happy to review your merge requests when you feel that you can contribute to, extend, or improved the software in any way. Please make sure that you make use of our approach to allow custom themes and modifications as described within the custom themes section of this page and the following principles.
Although this project is published on GitLab and GitHub we maintain the official project on GitLab
- Respect the API Terms (see GitLab Terms and GitHub Terms) There are terms and conditions when using APIs - respect them.
- Store / manage as little data as possible. Since this project is meant to be an interface it should mainly use the DevOp tools as a data source and store as little information as poissible within its own database.
- Don't break the permission and access control features of the DevOp tools - use them! Assign individual tokens to each user and don't use any method that allows access beyond the token-based permissions.