Deploying & Running the Pipeline

This lab is a little different because it demonstrates automation, which means there isn’t much for you to do after you run the script that kicks things off. So, we’ll show how you configure and run the deployment script. After that we’ll track what happens as the pipeline is deployed and runs through its four stages.

Stepping Through the Pipeline Script

The “/pipeline/pipeline.zsh” script creates a CloudFormation stack for the pipeline, similar to the deploy.zsh script you’ve been running for the sample code. Here’s the full script:

Stepping through this script, lines 3-9 validate the required command line argument that determines if the SAM or the OpenAPI version of the sample code is to be deployed. Lines 11-24 assign values to the variables used later in the script, mostly as CloudFormation parameters. Lines 32-45 are the create-stack command and its arguments. Note that this stack command creates the pipeline stack, not the solution stack.

Configuring & Running the Pipeline Script

Step 1: set the variables for the workspacePath and bucket variables

On lines 12-13 set the workspacePath and bucket variables. Note that this can be the same bucket used for the scripted deployments; the pipeline will create separate working folders in this bucket.

Step 2: run the pipeline.zsh script in the terminal

Once configured, run the script, using the “sam” argument as shown below. You’ll see the basic output for the “create-stack” command:

It doesn’t take long for the pipeline to deploy, so by the time you switch to CloudFormation in the console, you’ll probably find that the stack for the pipeline is already complete:

Tracking the Pipeline Execution

The pipeline automatically runs once it’s deployed, so if you navigate now to the CodePipeline service in the console, you should see the pipeline in progress, like this:

Click on the pipeline execution link, and you’ll be directed to this page, where you can see the progress in more detail:

At the point in the pipeline execution, shown above, the source stage has successfully checked out both the solution source code and the artifacts from the common repository. The build stage has also successfully executed. Click on the “Details” link, shown above, at the bottom of the page. You should see the log output for the CodeBuild action, something like this:

This log, depending on how verbose the commands are that the build is executing, can be quite long.

The next stage performs the CloudFormation deployment, which works exactly as our previous scripted deployments did, except that the CloudFormation parameters are set by the pipeline. When you look at the stacks in the console, you’ll now see that there is one stack for the pipeline, and another set of stacks for the deployed sample code:

An important thing to note here is that the “ConnectedCarPipelineDev” pipeline stack owns the “ConnectedCarDev” solution stack. Because of this, you must always delete the solution stack before deleting the pipeline stack. If you delete the pipeline stack first, CloudFormation will subsequently block you from deleting the solution stack. If you end up in this state, you have to redeploy and run the pipeline in order to re-establish the chain of ownership.

The last stage of the pipeline contains the CodeBuild project for the automated API tests. Again, the log output for this can be quite long. Here’s an example snippet of the output, showing the successful execution of the Customer API tests by Newton:

When you navigate back to the pipeline execution page, success will be indicated by the series of green checkmarks, one for each stage, on the right-hand side:

If you wanted, you could deploy this pipeline with links to cloned Github repositories for which you have permission to make changes. Then, after making code changes in one of these repositories, you could manually trigger the pipeline by clicking the orange “Release change” button at the top right.