Sharing IT Best Practices with youSharing IT Best Practices with youFrom all aspects of DevOps, the deployment pipeline is one of the most appealing unique features.
The deployment pipeline supports the delivery process of a DevOps team. This begins at the commit phase in which the source code is written and checked in and ends with the implementation of the objects in the production environment. In this article, the deployment pipeline also includes the definition of the themes, epics and features. This enables the tracking of dependencies in the deployment pipeline. This is also more efficient because of the defining the deployment pipeline E2E offers more control capabilities. This leads to faster feedback.
An important concept of the deployment pipeline is to ensure that all DevOps team members are involved in one feature, and the flow is free of waste.
One of the most difficult questions is how the deployment pipeline should look like. This is unique to all organisations. This article describes a simple approach for understanding the pipeline. It is based on an existing project in which the deployment pipeline is not recognized but where one wants to implement it.
Step 1. Select a project
Step 2. Determine the flow
Step 3. Determine the deployment pipeline
Step 4. Determine the waste
Step 5. Eliminate the waste by optimizing the deployment pipeline
Step 1. Select a project.
Select a project for which the deployment pipeline should be mapped. If the organisation just starts with DevOps, it is wise not to tackle the most complex project. Most organisations start with a low risk project such as a project for improving deployment of content.
Step 2. Determine the flow
Determine the steps of the flow from requirement to deployment:
Figure 1 gives an example of the flow from requesting report requirements up to and including deployment of a report.
The flow is described per step 1 in Table 1.
| Step | Input | Processing | Output |
| 1 | Userstory | Ask stakeholder the requirements for a new report | Registered Feature |
| 2 | Registered Feature | Refine the sprint backlog | Feature with priority |
| 3 | Feature with priority | Ask stakeholder to define the test cases for a priority feature | Registered Given-When-Then test case |
| 4 | Registered Given-When-Then test case | Ask development team to define tasks for the build of the feature | Filled sprint board |
| 5 | Filled sprint board | Realize tasks and build report | Created report in OBIEE repository |
| 6 | Created report in OBIEE repository | Test the report | Test output |
| 7 | Test output | Release the report if there are no errors occured | Released report |
Table 1, Flow decomposition.
Step 3. Determine the deployment pipeline
In Table 2 for each step the related tooling is indicated.
| Step | Input | Processing | Output | Tool |
| 1 | Userstory | Ask stakeholder the requirements for a new report | Registered Feature | HP ALM |
| 2 | Registered Feature | Refine the sprint backlog | Feature with priority | HP ALM |
| 3 | Feature with priority | Ask stakeholder to define the test cases for a priority feature | Registered Given-When-Then test case | HP ALM |
| 4 | Registered Given-When-Then test case | Ask development team to define tasks for the build of the feature | Filled sprint board | Whiteboard |
| 5 | Filled sprint board | Realize tasks and build report | Created report in OBIEE repository | OBIIE repository |
| 6 | Created report in OBIEE repository | Test the report | Test output | Fitnesse |
| 7 | Test output | Release the report if there are no errors occured | Released report | Nexus |
Table 2, The deployment pipeline.
Step 4. Determine the waste
The waste is determined by adding two columns to Table 1-2 as shown in Table 1-3. The two columns are the effective time spend in the step and the elapse time of the step. The effective time is the time which is spend and adds value. The elapse time is the waiting time and the wasted time. Wasted time is the time that is spend without adding value to the end result.
| Step | Input | Processing | Output | Tool | Time (hrs) | Elapse Time (hrs) |
| 1 | Userstory | Ask stakeholder the requirements for a new report | Registered Feature | HP ALM | 1 | 40 |
| 2 | Registered Feature | Refine the sprint backlog | Feature with priority | HP ALM | 4 | 5 |
| 3 | Feature with priority | Ask stakeholder to define the test cases for a priority feature | Registered Given-When-Then test case | HP ALM | 4 | 8 |
| 4 | Registered Given-When-Then test case | Ask development team to define tasks for the build of the feature | Filled sprint board | Whiteboard | 4 | 4 |
| 5 | Filled sprint board | Realize tasks and build report | Created report in OBIEE repository | OBIIE repository | 16 | 18 |
| 6 | Created report in OBIEE repository | Test the report | Test output | Test output in fitnesse | 8 | 30 |
| 7 | Test output | Release the report if there are no errors occured | Released report | Nexus | 1 | 5 |
| Total
(hrs) | 110 |
Table 3, Flow elapse time and effective time.
The elapse time and the effective time of each step are shown in Figure 2. Analysis of the delay in the deployment pipeline is, for example, between step 6 and step 7. Further analysis indicates that the test case contained in HP ALM must be manually typed into the Test automation tool Fitnesse. This step takes 30 hours of which 22 hours of waste can be eliminated by further automating the deployment pipeline and loading the HP ALM test cases automatically in Fitnesse.
A second bottleneck appears to be step 7. The release costs essentially only one hour, but the elapse time is 5 hours. The 4 hour waste is to determine the status of Fitnesse’s output. The status of the features in HP ALM is manually set to succeed by analyzing Fitnesse’s output. The status of the feature in HP ALM can be automatically set by sending the output of Fitnesse back to HP ALM after the test run. This can trigger the automatically deployment of the report into production by the use of Nexus.
With this, the deployment pipeline has been optimized and the TTM has been shortened by 26 hours. This is thus 26/110 * 100% = 23.6% time saving.
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.