Sharing IT Best Practices with youSharing IT Best Practices with you
The build server needs tools that collaborate together. This article is about the requirements for tooling and tool integration.
Meta data is information that describes objects. An example is the meta data of a build. This meta data may consist of:
The ID’s in objects are the unique objects identifiers. Many objects like a baseline and build have a relationship. There can now be a defined relationship between these objects by sharing a key field. For example, in the build object, a BaselineID can be included to indicate based on which BaselineID the build was built with the unique BuildID. The BaselineID is then the Primary Key that is registered in the Build object as a Foreign Key.
DevOps uses automation for the deployment pipeline. The tools that are used are either integrated or tightly coupled. In case that more tools are used, integration is a very important aspect. This includes:
In article #5 (DevOps Tooling Architecture) the architecture of tooling is described including the options of the make / buy and the tool integration or the best of breed choices. In article 16 (DevOps Software Configuration Items) the relationship between the CMDB and the S-CMDB is described.
The interface between the CMDB and the S-CMDB is not a common place challenge. Throughout the DevOps deployment pipeline, we see this discussion returning. This article addresses the main pitfalls of tool integration at the build.
The build must take place automatically and, of course, repeatable, stable and fast. Article # 21 (DevOps Build – CI) describes how the build works within CI. Herein the following objects have emerged:
There is a build for different types of objects, and the tooling must be able to relate these objects to each other.
To recognize these dependencies, it is best to use a data model. In the data model the objects, the relationship between the objects and the data attributes of those objects are defined. This can then be displayed in a graphics picture. But in a table form, it is also workable. It is important to determine the extent to which the tools cover this information need after this need is inventoried. Often there is something to configure to get the missing information above the table.
An example of such a data model is given in the following tables.
| Source code | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | SourceCodeID | Integer | ID of the S-CI |
| 2 | FK | BaselineID | Integer | Name of baseline to which the S-CI belongs |
| 3 | FK | DeveloperID | Integer | Name of developer who did change the S-CI the last time |
| 4 | FK | DependencyID | Integer | ID of the S-CI that must be compiled before this S-CI can be compiled. Assumed is one dependency, but probably there will be more dependencies which may need a 1:N relationship (extra table) |
| 5 | FK | CI-ID | Integer | ID of the CMDB to which this S-CI Belongs |
| 6 | FK | LastBuildID | Integer | Last build that made use of this S-ID |
| 7 | Name | Varchar (255) | Name of S-CI | |
| 8 | Version | SmallInt | Version of the S-CI | |
| 9 | DateTime CheckIn | Datetime | Date and time of the last check-in | |
| 10 | Change | Varchar (255) | Oneliner with the change description | |
| 11 | … | … | … |
Table 1, Sourcecode meta-data tooling
| Build | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | BuildID | Integer | ID of the Build |
| 2 | FK | BaselineID | Integer | Name of baseline to which the S-CI belongs |
| 3 | FK | DeveloperID | Integer | Name of developer who did invoke the build |
| 4 | FK | DependencyID | Integer | ID of the S-CI that must be compiled before this S-CI can be compiled. Assumed is one dependency, but probably there will be more dependencies which may need a 1:N relationship (extra table) |
| 5 | FK | CI-ID | Integer | ID of the CMDB to which this build Belongs |
| 6 | BuildDateTimeStart | DateTime | Date and Time of the start of the build | |
| 7 | BuildDateTimeEnd | DateTime | Date and Time of the end of the build | |
| 8 | BuildDuration | Integer | Number of seconds of the duration of the Build | |
| 9 | CompileErrorNumber | Integer | Number of errors found in the build | |
| 10 | CompileWarningNumber | Integer | Number of warnings found in the build | |
| 11 | … | … | … |
Table 2, Build meta-data tooling
| Objectcode | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | ObjectCodeID | Integer | Name of the object |
| 3 | FK | BuildID | Integer | ID of the build that did create this object |
| 4 | FK | CI-ID | Integer | ID of the CMDB to which this object belongs |
| 5 | … | … | … |
Table 3, Objectcode meta-data tooling
| Test case | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | TestCaseID | Integer | ID of the Test Case |
| 2 | FK | ObjectCodeID | Integer | ID of the object that is tested. In case of more Objects the data model must be expanded to support a 1:N relationship (extra table) |
| 3 | FK | CI-ID | Integer | ID of the CMDB to which this object belongs |
| 4 | TestType | Char(3) | UT, ST, SIT, FAT, PAT, UAT | |
| 5 | Pre-condition | What is needed to perform this test like test data and authorization. | ||
| 6 | Test execution | Given – When – Then | ||
| 7 | Post-condition | What is the result in terms of errors, data in the database, information on screen | ||
| 8 | ExpectedResult | Succeed test or Failure test. | ||
| … | … | … |
Table 4, Testcase meta-data tooling
| Test run | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | TestRunId | Integer | ID of the Test Run |
| 2 | FK | TestCaseId | Integer | Test case that is tested in the test run. For each Testcase that is part of the Test run a record has to be present |
| 3 | DateTime | DateTime | If filled in the test run, must wait for this time trigger to start | |
| 4 | Result | Varchar(255) | The result of the test | |
| 5 | ContinueFlag | Char(1) | “Y” means continue the run “N” means stop the run in case of a failure of this testcase. For unit test cases the flag is always set to “Y”. |
Table 5, Test run meta-data tooling
| Defects | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | DefectID | Integer | ID of the defect |
| 2 | FK | TestRunID | Integer | ID of the test run in which the test did take place |
| 3 | TestCaseID | Integer | ID of the test case that caused the defect |
Table 6, Defect meta-data
| Documents | ||||
| F# | Type | Name | Type | Description |
| 1 | PK | DocID | Integer | ID of the documentation |
| 2 | FK | Baseline | Integer | ID of the baseline for which the documentation is valid |
| 3 | FK | BuildID | Integer | ID of the build that generated the document |
Table 7, Document meta-data
Based on the meta data tables, a number of requirements for the tools can be derived as defined in Table 8.
| Requirements | ||
| R# | Requirement | Links |
| Source code repository tool | ||
| S-01 | Each source object has an unique ID | |
| S-02 | The check-in on the baseline is personalized | Probably based on a link to active directory tool |
| S-03 | The source code repository must be able to defined dependencies | |
| S-04 | The source code repository must be able to relate a S-CI to an CI | This requires a link to the CMDB tool |
| S-05 | The compiler must be able to update the S-CI to register the lastbuildID | This requires a link to the build server tool |
| S-06 | The source code repository must use versioning and require a checkin | |
| Build Server tool | ||
| B-01 | The build server must register the builds that have been invoked | |
| B-02 | The build server must administrate the baselineID for which the build was | This requires a link to the source code repository tool |
| B-03 | The build server must look up dependencies or be able to determine them based on the source code files | This requires a link to the source code repository tool |
| B-04 | The build server must relate the objectID to a CI | This requires a link to the CMDB tool |
| B-05 | The build server must administrate where the object is placed in the object artefactory | The requires a link to the artefact repository tool |
| Test automation tool | ||
| T1 | Test cases must be registered uniquely | |
| T2 | The test case must have a relation with an object ID | This requires a link to the artefact repository tool |
| T3 | The test case must relate to the CI | This requires a link to the CMDB tool |
| T4 | Test execution | If the Given-When-Then is a requirement that is defined in a requirement tool, then there is a need for a link to that tool as well. |
| T5 | The execution of a set of test cases in a run is administrated | |
| T6 | The test run must refer to the defined test cases | If the test run and the test cases are not defined in the same tool, then an extra link is needed |
| Defect management tool | ||
| D1 | The defects are uniquely identified | |
| D2 | There is a relationship between defect and TestRunID / TestCaseID | This requires a link with the test automation tool. |
| Document generation tool | ||
| G1 | Documents are registered based on an unique ID | |
| G2 | Documents are based on a baseline | This requires a link to the source code repository tool |
| G3 | Documents refer to the build in which there are generated | This requires a link to the build service tool |
Table 1‑8, Toolrequirements
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.