Adopting a DevOps approach by using IBM Cloud Continuous Delivery
This unit covers the following topics:
•IBM Cloud Continuous Delivery overview
•Web IDE (Edit Code)
•Source Code Management (Git Repo) and Issue Tracker
•Automated Delivery Pipeline (Build & Deploy)
4.1 What you should be able to do
After completion of this unit, you should be able to:
•Describe DevOps
•Describe the capabilities of IBM Cloud Continuous Delivery
•Identify the Web IDE features in IBM Cloud Continuous Delivery
•Describe how to use Git Repos and Issue Tracking
•Explain the pipeline build and deploy processes
4.2 References
The following publications are useful for further research on the topic presented in this unit:
•Open source Git project:
•Continuous Delivery Docs:
•IBM Cloud Garage Method:
•IBM DevOps tools and methodologies from IBM:
•Develop a Cloud Foundry app toolchain:
4.3 What is DevOps?
Figure 4-1 What is DevOps?
Notes:
Before DevOps, the following teams were responsible for code delivery:
•Development team: This team designed the code, delivered new features, fixed bugs, and tested the code.
•Operations team: This team deployed the code to the different environments, maintained the uptime on production, and diagnosed failures.
The term DevOps comes from merging the words development and operations. With DevOps, both teams work together to support the software lifecycle, from code design to deployment to production. This collaboration includes automating all of the tasks.
A developer can use DevOps processes, automation, and other tools to automate the build process, code testing, deployment to the different environments, and monitoring. It is an active and continuous task to keep the automation, pipelines, and other entities in this realm up to date and even improve them, as it is also an active and continuous task developing code.
4.4 Benefits of DevOps
Figure 4-2 Benefits of DevOps
Notes:
DevOps provides many benefits:
•From code to production in minutes: Work on your own or use the collaboration tools to work with a team. In minutes, you can go from source code to a running app.
•Accelerate app delivery: Innovate like a startup, and scale for the enterprise. You can host an open source project, run a hackathon, or start a skunkworks project. Plan anything, even monthly meetings. DevOps code is continuously delivered and integrated into the main shared repository.
•Deploy with confidence:
– Leverage the repeatability of the process by using automation, which ensures that the same steps are executed every time you deploy.
– Leverage automated testing as a quality gate before deploying code to a specific environment, or in some cases, to enable the monitoring or testing of the code in a live environment.
4.5 What is IBM Cloud Continuous Delivery?
Figure 4-3 What is IBM Cloud Continuous Delivery?
Notes:
DevOps is a software methodology that integrates application development and IT operations so that teams can deliver code faster to production and iterate continuously based on market feedback.
Although the IBM Cloud catalog provides multiple tools for DevOps, this unit is focused on IBM Cloud Continuous Delivery.
By using Continuous Delivery, you can build, test, and deliver applications by using DevOps practices and industry-leading tools.
The Continuous Delivery service supports your DevOps workflows with the following capabilities:
•Create integrated DevOps open toolchains to enable tool integrations that support your development, deployment, and operations tasks. A toolchain is an integrated set of tools that you can use to collaboratively develop, build, deploy, test, and manage applications and make operations repeatable and easier to manage. Toolchains can include open source tools, IBM Cloud services, such as IBM Cloud DevOps Insights, and third-party tools, such as GitHub, PagerDuty, and Slack.
•Deliver continuously by using automated pipelines. Automate builds, unit tests, deployments, and more. Build, test, and deploy in a repeatable way with minimal human intervention. Be ready to release into production at any time.
•Edit and push your code from anywhere by using the web-based IDE. Create, edit, run, and debug, and complete source-control tasks in GitHub. Seamlessly move from editing your code to deploying it to production.
•Collaborate with your team and manage your source code with a Git repository (repos) and issue tracker that is hosted by IBM and built on GitLab Community Edition. Manage Git repos through fine-grained access controls that keep code secure. Review code and enhance collaboration through merge requests. Track issues and share ideas through the issue tracker. Document projects on the wiki system.
For more information about how to create an open toolchain, which includes the minimum tools that you need to develop and deploy a “Hello World” app to Cloud Foundry (including Git Repos and Issue Tracking), see Develop a Cloud Foundry app toolchain.
4.6 What tools does IBM Cloud Continuous Delivery provide?
Figure 4-4 What tools does IBM Cloud Continuous Delivery provide?
Notes:
IBM Cloud Continuous Delivery provides the following tools:
•Web IDE
You can develop your code (for example, Node.js, Java, or other languages) in this web-based integrated development environment (Web IDE). No software other than your web browser is necessary. The Web IDE saves your current work in a cloud-based file directory, which is known as the local repository. IBM Cloud provides Eclipse Orion as the Web IDE. You can also use a desktop IDE, such as Eclipse with DevOps services.
•Source control management (Git Repo) and Issue Tracker
IBM Cloud Continuous Delivery creates a Git repository as a change management system. The local repository is a copy of your latest edits before you submit your work to a SCM system. The Git repository, which is known as the remote repository, is hosted on the IBM Cloud DevOps infrastructure. Issue Tracker is part of the functionality of the Git Repo; it tracks your work, including defects, enhancements, and tasks.
•Delivery Pipeline
This tool automates the process of building and deploying your code as an IBM Cloud application. You can also configure the build, deploy, or test scripts within the Web IDE.
4.7 Additional DevOps services
Figure 4-5 Additional DevOps services
Notes:
In addition to the Continuous Delivery service, the IBM Cloud Catalog provides multiple services to enable end-to-end DevOps, such as Auto-scaling and Monitoring. You can access these services from the Catalog by clicking DevOps in the platform category.
We focus on the Continuous Delivery service.
4.8 Adding Continuous Delivery
Figure 4-6 Adding Continuous Delivery
Notes:
After you enable Continuous Delivery for your app, a new tab opens to configure Continuous Delivery Toolchains.
4.9 Creating Continuous Delivery Toolchains
Figure 4-7 Creating Continuous Delivery Toolchains
Notes:
A toolchain is a set of tool integrations that support development, deployment, and operations tasks.
The UI to create a toolchain groups the tools into the following phases:
•THINK: This phase is for planning the application by creating bugs, tasks, or ideas by using the Issue Tracker, which is part of the Git repository.
•CODE: This phase is for the implementation of the application by providing a GIT repository as source code management system, and a Web IDE (Eclipse Orion) to edit your code online. In the repository, you can specify whether to clone a repository or start from scratch by selecting New in the repository type.
•DELIVER: This phase is for configuring the delivery pipeline. It allows you to specify automatic build, deployment, and testing of your code after a developer pushes new code to the Git repository.
•RUN: The output of this phase is to run the application in the IBM Cloud environment.
For more information about the phases of developing a Cloud Foundry app toolchain,refer to the IBM Cloud Garage method:
4.10 Adding Tools to the Toolchain
Figure 4-8 Adding Tools to the Toolchain
Notes:
To add tools, click Add a Tool from within a toolchain.
4.11 Adding Tool Integration to a Toolchain
Figure 4-9 Adding Tool Integration to a Toolchain
Notes:
The collective power of a toolchain is greater than the sum of its individual tool integrations.
In the Tool Integrations section, select each tool integration that you want to configure for your toolchain. Consider the following examples:
•If you configure Sauce Labs, the toolchain is set up to enable adding Sauce Labs, which you can use to add test jobs to the pipelines.
•If you configure PagerDuty, the toolchain is set up to send alert notifications to the specified PagerDuty service when a major issue occurs.
•If you configure Slack, the toolchain is set up to send notifications to the specified Slack channel.
•If you configure a source code tool integration, such as GitHub, the sample repo can be cloned or forked (for example) into your GitHub account.
4.12 Web IDE: Edit Code features
Figure 4-10 Web IDE: Edit Code features
Notes:
The Web IDE features in IBM Cloud Continuous Delivery provide the following capabilities:
•Uses Eclipse Orion Web IDE.
•No installations required; use a browser to code.
•The Edit Code feature provides a workspace to develop source code and configuration files.
•Full-featured environment for writing your application code by using your web browser.
•Rich code completion capabilities for CSS, HTML, and JavaScript.
•Deploy, stop, and run applications from the Run bar.
•View the logs from the Run bar.
IBM Cloud Live Sync features (as of this writing, available for Node.js applications only):
•Live Edit: Allows you to make changes to your application from the Web IDE without the need to redeploy it.
•Debug: When a Node.js application is in Live Edit mode, you can shell into it and debug it. You can edit code dynamically, insert breakpoints, step through code, restart the runtime, and more by using the Node Inspector debugger.
4.13 Web integrated development environment
Figure 4-11 Web integrated development environment
Notes:
The Edit Code perspective for Eclipse Orion Web IDE is shown in Figure 4-11.
When you select a file, the editor displays the contents on the right side of the page. You can edit source code, configuration files, and other artifacts directly within your web browser.
This view is for your local workspace on IBM Cloud. To commit the code changes, switch to the GIT view (described next).
4.14 Editing source code
Figure 4-12 Editing source code
Notes:
When you open a Node.js script file, the editor provides real-time validation and syntax checking of the source code. It uses tools, such as JSHint, which is a JavaScript code quality tool that helps detect errors and potential problems in the code. A preview window flags warnings and errors.
4.15 Editor features: Code completion
Figure 4-13 Editor features: Code completion
Notes:
To use the code completion shortcut, place your cursor within the editor and press Ctrl + Space bar. This feature displays the libraries that are available at the cursor point, including third-party modules that you imported in the script. For example, as shown in Figure 4-13, the code completion feature displays functions and templates for the Express web application framework for Node.js because this point is the cursor point.
You can use templates to add blocks of code for common tasks, such as error handling or object creation.
4.16 Editor features: Run bar
Figure 4-14 Editor features: Run bar
Notes:
You can quickly build and deploy your application to a test environment on IBM Cloud without committing your code to the Git repository. The following features are highlighted in the slide:
1. The status area displays the launch configuration that the run bar uses during the build and deploy task.
2. Click the Play icon from the Run bar to build and deploy the code in your user directory to your IBM Cloud account.
3. Click the Stop icon to stop the application.
4. Click the Open Deployed App icon to open the application route.
5. Click the Open Logs icon to open application logs.
6. Click the Access icon to access the dashboard from the same bar.
4.17 IBM Cloud Live Sync features
Figure 4-15 Cloud Live Sync features
Notes:
If you are building a Node.js application, you can use IBM Cloud Live Sync to quickly update the application instance on IBM Cloud and develop without redeploying.
When you make a change, you can see that change in your running IBM Cloud application immediately (without the need to recompile and redeploy).
IBM Cloud Live Sync works from the Web IDE and consists of the following features for Node.js applications:
•Live Edit
You can change a Node.js application that is running in IBM Cloud and test them in your browser immediately. Any changes that you make in a synchronized desktop directory or in the Web IDE are instantly propagated to the application’s file system.
•Debug
When a Node.js application is in Live Edit mode, you can debug it on the Web IDE. You can edit code dynamically, insert breakpoints, step through code, restart the runtime, and more.
|
Note: You must use a Chrome browser to use the Debug feature.
|
4.18 Git Repos and Issue Tracking
Figure 4-16 Git Repos and Issue Tracking
4.19 Source control with a Git repository
Figure 4-17 Source control with a Git repository
Notes:
By default, enabling Continuous Delivery for an application creates a Continuous Delivery Toolchain for your application. This Toolchain includes a Git repository that is based on GitLab. Git is an open-source change management system.
The Git repository perspective in the Web IDE supports common Git commands to manage your code. You can also develop your application on your own workstation and commit your changes to the Git repository with a standard Git client.
For more information, see the open-source Git project at this website:
4.20 Git repository overview
Figure 4-18 Git repository overview
Notes:
The numbers that are shown in Figure 4-18 correspond to the following steps:
1. Switch to the Git perspective from the navigation bar on the left side of the web IDE.
2. You can review the commit history with the time/date for each commit. You can perform actions for each commit, such as view the files committed and revert changes that were introduced by any commit.
3. The Working Directory Changes pane detects any updated files in the user directory files. Click a file to review the changes that were made in that file.
4. Select the files that you want to commit and add a descriptive comment about the change.
5. Click Commit to commit the changes to your local repository.
6. The Outgoing pane lists the files that you want to commit to the remote repository. View the outgoing changes; then, click Push to push the committed changes to the remote repository.
If another user updated the files in the remote repository, the Incoming pane lists the updated files.
4.21 Connect a Git client to your repository on IBM Cloud
Figure 4-19 Connect a Git client to your repository on IBM Cloud
Notes:
You can still develop your application on your own local workstation.
If you do not have a Git client installed, download and install the latest version of the Git client from this website:
To verify that the installation is successful, issue the git --version command from the command line.
To find the URL of the git repository that is associated with your application, click View toolchain from the Application Details; then, click Git.
Start by retrieving a copy of the IBM Cloud application source code by using the git clone command. Issue git clone $git-URL on your Command Prompt. After you have a copy of the source code, use a text editor or integrated development environment to write and test your application.
To check whether another developer on your team updated the source code, run the git status command.
To save the updated source code, run the git add command to stage the files to be committed.
Then, run the git commit command and enter a message for the history log to commit all the added files to your local repository.
Finally, run the git push command to send your committed changes to the remote repository.
4.22 Issue Tracking tool
Figure 4-20 Issue Tracking tool
Notes:
The Issue Tracking tool (Issue Tracker in Figure 4-20) is part of Git Repos and Issue Tracking. It is used to track items (issues) that require resolution or improvements in a project.
Issues can be bugs, tasks, or ideas to be discussed. Also, issues are searchable and filterable.
4.23 Creating an issue
Figure 4-21 Creating an issue
Notes:
Complete the form that is shown in Figure 4-21. Then, click Submit issue to create the bug or task.
4.24 Delivery Pipeline
Figure 4-22 Delivery Pipeline
Notes:
By default, IBM Cloud Continuous Delivery automatically runs the build and deploy tasks when you commit changes to the Git repository. The pipeline also features a “run” icon that runs a stage of the pipeline but only runs on committed code or builds, depending on the stage.
You can access the Continuous Delivery toolchain by clicking View toolchain from the Application Details page. To browse to the delivery pipeline (or any other tool), click its tool card in the toolchain overview page.
Jobs (Build, Deploy, and Test) are grouped into stages. You can change the order of the stages by moving them by dragging and dropping.
4.25 Customizing Delivery Pipeline
Figure 4-23 Customizing Delivery Pipeline
Notes:
You can configure each stage to include one or more jobs (Build, Deploy, and Test). You can also configure a stage to include more than one job of the same type. For example, you can have a stage that features one Build job, one Deploy job, and two Test jobs.
4.26 Example: Default delivery pipeline
Figure 4-24 Example: Default delivery pipeline
Notes:
The default build script is simple: It takes the files that are pushed to the remote Git repository and triggers IBM Cloud to build your code in the server runtime.
After the build stage completes successfully, the deploy stage runs. Delivery Pipeline deploys the built files to your IBM Cloud space.
4.27 Configuring the Build Stage
Figure 4-25 Configuring the Build Stage
Notes:
By default, Delivery Pipeline runs the Build stage when a client pushes any change to the master branch in the remote Git repository.
If you do not want to automatically push your changes to your IBM Cloud account, change the State trigger setting to Run jobs only when this stage is run manually.
4.28 Configuring Build jobs
Figure 4-26 Configuring Build jobs
Notes:
You can extend the features of the build stage by adding jobs. Although by default Delivery Pipeline names this stage configuration the Build Stage, you can add build, test, or deploy jobs.
At the time of this writing, Builder Type supports the following types:
•Simple
•Ant
•Container Registry
•Gradle
•Grunt
•IBM Globalization Pipeline
•Maven
•npm: For Node.js projects
•NPM Build
•Shell Script
The simple build type runs the appropriate build scripts for your runtime environment. For example, the IBM SDK for Node.js runtime resolves modules that your application requires.
4.29 Configuring Deploy jobs
Figure 4-27 Configuring Deploy jobs
Notes:
In this example, you create a deploy task that pushes the application to a specific space on IBM Cloud.
The following Deployer Types are available:
•Cloud Foundry: Deploys applications to Cloud Foundry servers. This type is the default deployer type for the deploy job.
•Kubernetes: Provides a set of default deployment patterns for containers on Kubernetes Cluster. Containers are typically built by using the Docker Builder.
In this example, your application is pushed to the development space in your organization. You can also publish your application to your staging and production spaces.
You can customize the Cloud Foundry command-line interface commands (cf CLI) in the deploy process in the Deploy Script section. The default deploy action is equivalent to running the cf push command from the CLI. You also can add custom shell script commands. (${CF_APP} in Figure 4-27 refers to the application name).
4.30 Configuring Test job
Figure 4-28 Configuring Test job
Notes:
After the Deploy job is completed, you can add and configure a Test job to test your deployed application.
The following Tester types are available:
•Simple
•Advanced Tester
•DevOps Insights Gate
•IBM AppScan® Dynamic Analyzer
•IBM Security Static Analyzer
•Sauce Labs
•Vulnerability Adviser
4.31 Example: A successful build and deploy result
Figure 4-29 Example: A successful build and deploy result
Notes:
The default settings for the Delivery Pipeline are the following stages:
•Build Stage:
– Input: This stage is triggered whenever a change is pushed to Git.
– Jobs: Simple Builder Type.
•Deploy Stage:
– Input: This stage is triggered whenever the Build Stage is completed successfully. It takes as input the build artifacts that were produced from the Build stage.
– Jobs: Deploys the application to IBM Cloud.
In this example, all of the jobs in the Build Stage and Deploy Stage were completed successfully, as shown in the JOBS pane of the Build Stage and Deploy Stage.
The LAST EXECUTION RESULT pane shows that the application was successfully deployed to your IBM Cloud account, and that the application is running on IBM Cloud.
You can also check the build logs in the JOBS pane in the Build Stage column, the deploy logs in the JOBS pane in the Deploy Stage column, and the runtime logs from LAST EXECUTION RESULT pane in Deploy Stage column.
You can also clone the Deploy Stage and deploy the application to any number of spaces in your IBM Cloud account by clicking the settings wheel icon on top of Deploy Stage and selecting Clone Stage.
4.32 Unit summary
Figure 4-30 Unit summary
4.33 Checkpoint question
Figure 4-31 Checkpoint question
4.34 Checkpoint answer
Figure 4-32 Checkpoint answer
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.