2018-06-24 A lot of preliminary steps have been taken to billing by the hour (and not only by the hour) through GitLab, as the close of the second quarter is on the doorstep and it’s high time to knock it out.
- GitLab updated to the latest version (with saving data 🙂 ), at the same time configured its built-in PostgreSQL so that you can ignore the connection to the record from scripts.
- The connection with this postgres through the postgres dblink function was mastered, so that you can find out the time logs in the gitlab in one request and keep records in the database inspection (the option of recording directly in the gitlab database was not considered).
- The sysadmws/accounting project has been created – the repositories of this project will store yaml files with a description of clients, their servers and tariffs. For example:
clients/client.yaml: name: 'Client' active: True servers: - fqdn: 'srv1.client.ua' active: True tariffs: - date: '2016-09-01' tariffs: - file: 'server-support-basic-1.yaml' - fqdn: 'dev.client.ua' active: True tariffs: - date: '2016-09-01' tariffs: - file: 'server-support-basic-1.yaml' tariffs/server-support-basic-1.yaml: service: 'Server Support' plan: 'Basic' revision: '1' monthly: rate: '1500' currency: 'UAH' hourly: rate: '300' currency: 'UAH'
And in the tickets of this project, reports and invoices will be generated.
- Previously, such information was stored in pillars. Practice had shown that this idea was not very good (slow budget generation, the inability to bind to the client as a whole, and not to the server, and other problems). Now extended customer information and information about billing and tariffs will move to these separate yaml files. This will allow you to build a budget quickly, write automatic generation of bills for a subscription for customers, and much more.
- The first step for building hourly operations invoices is pre-written – a report on closed tickets. When the script is run, the SWS Bot gitlab user creates a ticket, where the Markdown table lists closed tickets since the last run. Several fields are compared with the date from the internal structure of the GitLab database, so that if the ticket is reopened or updated, including new hourly operations, it will again be included in the report.
- By the way, the hourly operations (timelogs) are taken into account in the gitlab very correctly: for each log there is a separate entry in the table. This will allow you to mark the already paid hourly operations in the service table. Which in turn will allow you to implement partial payment for tickets. For example, to take into account the work of engineers in one eternal ticket without closing and opening new ones. Or finish the client in a reopened ticket and issue an invoice for the finished ticket.
- The report generation script needs to be rewritten in python + in the process of working with the report, it became clear that information about the client’s servers in the ticket is very necessary to check the report. Without this information, it is difficult to decide whether an hourly closed ticket is indeed hourly, or a non-hourly closed ticket is not hourly.
- Therefore, a python script was written that recursively goes through the yaml files of the accounting repository, finds servers there and creates or updates labels in the Project Labels of the client project by the name of the servers in accounting with a tariff description in the label description. After automating the launch of this script and filling the client database in tickets, it will be easy to see the list of client servers in the Labels section, specify the desired server in the labels, see the hourly or subscription server in the server description, and so on. The field is optional, but should greatly simplify the maintenance of the hour in tickets.