A deployment pipeline composed of steps from remote servers

Size: px

Start display at page:

Download "A deployment pipeline composed of steps from remote servers"

Aubrie Benson
5 years ago
Views:

1 If someone wanted to implement... A deployment pipeline composed of steps from remote servers This deck outlines the scenario, to start discussion about the use of OSLC Automation to enable it. See the OASIS Automation TC wiki pages: Jenkins is an example. Any other tool could do this by becoming an OSLC consumer. This deck uses Chef Server as a deployment example. You could substitute any other deployment server wherever that is mentioned and I expect the flow would be the same. Assumptions: Jenkins and other servers already set up as friends.using OSLC Automation How would they do it? This deck is not proposing an implementation of this, it is merely an example scenario for discussion.

2 Why would someone want to do this? What benefit does it give over existing solutions? BEFORE Pipeline engineers writing scripts (which may or may not be called by Jenkins) to hit servers' vendor-specific APIs (whether that be native language (Ant/JS/Python) APIs, or REST APIs). Pipeline engineers not only need knowledge of the servers' domain models, but also knowledge of each server's API. The composed pieces of the pipeline are only visible in the script, not in a UI which not only makes seeing an overview of it hard, but to see each of the stages progressing requires careful tailoring of the script console output. Even when using the same APIs, this might result in wildly different scripts between teams less reusable knowledge. AFTER Pipeline engineers compose a pipeline in Jenkins UI, with consistency in how each step is added to the pipeline (but still allowing server-specific dialogs just enough specialization to support different domain models). Pipeline engineers only need knowledge of the servers' domain models, plus a onetime familiarization with how to add a step to the pipeline (which is now the same for all components). The composed pieces of the pipeline can be shown in a high-level overview in the UI both at design time and to see each of the stages progressing as it runs. Between teams that are using this tool, there is consistency more reusable knowledge which aids maintenance.

4 (Other build steps omitted) This is the fictitious implementation that this scenario is discussing

5 Chef Server (chef.intranet.example.com) The user selects the server they want to connect to (from a drop-down list that would have been populated at a previous time in Jenkins' settings. Alternatively they could add a new one at this time not shown in this mock up.) In this case we're connecting to a fictional Chef Server OSLC interface.

6 Chef Server (chef.intranet.example.com) Displays: Delegated UI dialog rendered in Jenkins by target server (in this case, Chef Server). Can expose whatever UI is needed for the target server's domain model.

7 Chef Server (chef.intranet.example.com) Parameters specific to selected plan Environment pre-populated from previous dialog (but could be replaced with variable if desired).

8 Chef Server (chef.intranet.example.com) Displays

9 Chef Server (chef.intranet.example.com) ${BUILD_TAG} Jenkins inserts variable name The deployment has been configured as part of the pipeline with zero scripting, with no custom interfaces all using web UIs that are specific to the target server, but without a custom Jenkins plug-in specific to that target server. We'll continue on to adding a test step into our pipeline composition...

10 Assumption: The deployment definition is written to know where to find the build artifacts for a given build tag. Ideally the less the deployment plan knows about the pipeline the better, so if there is any open standards for artifact repositories then it would be good to use that here. In this case, perhaps the build script could have pushed the artifacts to the deployment server that would be one option.

11 User adds another new build step, to execute the automated tests (Prior build steps omitted)

12 Karma Server (karma.intranet.example.com) Automated tests The user selects the server they want to connect to (from a drop-down list that would have been populated at a previous time in Jenkins' settings. Alternatively they could add a new one at this time not shown in this mock up.) In this case we're connecting to a fictional OSLC-enabled Karma server. As before, by clicking the select button the user gets a dialog that allows then to choose (and, optionally, configure) a test plan to add to the pipeline.

13 Karma Server (karma.intranet.example.com) Automated tests Test plan: Automated functional test suite If the dialog did not give the user a chance to set the environment, they can enter it manually here. User clicks save to save the build job definition So when the build is triggered, it can coordinate the execution of various pipeline activities from multiple tools/servers.

Jenkins pipeline view An additional benefit of Jenkins is the ability to place the build and deploy & test steps into separate build definitions, then use the pipeline view plug-in for Jenkins to

14 Jenkins pipeline view An additional benefit of Jenkins is the ability to place the build and deploy & test steps into separate build definitions, then use the pipeline view plug-in for Jenkins to view the progress of the build along the pipeline. With OSLC this becomes a generic pipeline view for the composed pipeline made up of steps from multiple tools across a loosely-coupled integration. (Existing Jenkins plug-in)

SDD Proposal to COSMOS

IBM Tivoli Software SDD Proposal to COSMOS Jason Losh (SAS), Oasis SDD TC Tooling Lead Mark Weitzel (IBM), COSMOS Architecture Team Lead Why: Customer Problems Customer Feedback More than half of outages