As an IT architect or IT professional, you are essential to the success of your organization, responsible for designing, building, and maintaining the IT systems that your businesses and governments rely on. As if that wasn’t enough, you’ve also got to constantly learn and adapt to keep up with the demand of an ever-changing IT landscape — especially when technologies like generative AI suddenly emerge and become a crucial part of your business. Did you know that 77% of companies are using or plan to use AI in the future? And that’s growing year over year. Then there are the constant firedrills, a contributing factor in 40% of IT professionals being at risk of burnout. So, the fundamental question you’re asking yourself is: how can I do my job successfully, but with less toil and stress?

Well, we come with good news! First, Google Cloud has a plethora of ways to help you evolve your IT landscape quickly, easily, and effectively. And second, our upcoming event, Google Cloud Next ‘23 from August 29th to 31st, is exactly what you need to learn more about capitalizing on those opportunities. But if you’re still on the fence about going, let’s power through five scenarios that might be on your plate right now, and how Next ‘23 can help you  

#1 — Architect infrastructure for AI workloads 

Chances are good that you’ve been asked to spin up new resources to run emerging AI-based applications on. At Next ‘23, we’ll show you how you can innovate, scale and optimize workloads quickly, safely, and cost effectively with purpose-built infrastructure that has AI efficiencies baked-in. Google is an AI-first company, so our AI-optimized infrastructure is built to deliver the global scale and performance demanded by our own products such as YouTube, Gmail, Google Maps, Google Play, and Android, all of which serve billions of users. It’s also designed for intensive workloads like training and serving large language models like PaLM 2, the basis of generative AI features and tools Bard and the PaLM API. 

Google’s deep experience in AI and cloud computing means that Google Cloud is uniquely positioned to present one of the strongest AI infrastructure offerings on the market. Here’s a few ways you can learn about our AI infrastructure during Next ‘23: 

• Watch our exciting spotlight session “What’s next for architects and IT professionals,” where our GMs will explore what’s coming for infrastructure and AI/ML. 
• Attend our “Build your organization’s future on Google AI and machine learning infrastructure” breakout session, or check out dozens of others on AI/ML. 
• Visit our AI Innovation pavilion within our Demo Showcase. 
• Get hands on (literally!) with some of our AI infrastructure at our Hardware-verse.
• Upgrade your AI/ML skillsets with our live training workshops at the Innovators Hive.

#2 — Build and run modern container-based applications quickly and securely 

Your org has no doubt been using containers and Kubernetes for years, but are they Google Cloud containers and Kubernetes? Google Cloud provides one of the best places to run modern containerized workloads, packaging more than a decade’s worth of experience launching several billion containers per week into our offerings, so that developers and businesses of many sizes can tap the latest in container innovation. 

IT pros who are building modern, container-based applications often choose Google Cloud because of its managed services and range of database options, so developers can quickly build applications securely and at scale. For these types of use cases, here’s where you should spend some time during Next ‘23: 

• Watch our GM Spotlight session “What’s next for IT operations,” which will dive deep into everything from containers to AI. 
• Learn how legendary gaming company CAPCOM is running Street Fighter 6 on Google Cloud in this breakout session “The future of modern enterprise applications with Google Kubernetes Engine,” and browse all our other great container sessions. 
• Come and mingle with your friends and peers in our Innovators Hive Community Hub.
• Watch our Innovator Hive Lightning Talk “How to run ML workloads in GKE with Cloud TPU and GPU.”
• Visit our Containers area at the Demo Showcase.

#3 — Boost traditional enterprise applications with high reliability, scale, and price-performance

Cloud-native workloads are great and all, but traditional enterprise workloads such as ERP, databases, web apps, and mainframes continue to be the lifeblood of the organization. These workloads will likely not disappear. They are evolving into more modern versions of themselves — often with major opportunities for modernization using data analytics and AI. Now more than ever, CIOs have to ensure these workloads are healthy and thriving.     

Google Cloud ensures that our platform design and choices are centered on real-world workloads like SAP and VMware. We simplify the migration and modernization decision-making process so customers can get to the cloud confidently with an intuitive set of options and prescriptive solutions that deliver better reliability, security, scale, performance, and cost. At Next ‘23, there are a ton of ways to learn more about solving these challenges: 

• No matter what you’re looking to deploy or migrate, we’ve got a breakout session for you. For starters, check out “How Sabre migrated their apps and data centers to Google Cloud with speed and ease,” “Accelerate innovation with SAP on Google Cloud,” or any of these others.
• Explore how our customer ADT successfully migrated their VMware estate to Google Cloud by visiting their interactive story in our Demo Showcase.
• Click through Migration Center, our unified service for end-to-end migration and modernization, as well as other demos at our Architect’s Corner of Innovators Hive.

#4 – Run on high performance, distributed infrastructure

Google Cloud’s infrastructure isn’t limited to what we run in our data centers. If your business or government needs infrastructure designed for sovereignty, scale, security, and high-intensity compute workloads, we’ve got exactly what you need:

• For governments and highly regulated businesses, we have unique offerings and services including Google Distributed Cloud Hosted and Google Cloud Sovereign Solutions for organizations with specific sovereignty and security needs. 
• For Telecommunications, we have purpose-built telecom offerings to help Communication Service Providers (CSPs) digitally transform their networks with hybrid cloud principles and identify new revenue opportunities. In addition, we have Google Distributed Cloud Edge which provides an open, Kubernetes-based offering tuned for telecom network workloads.

• Telecoms should also be sure to check out “How Google Cloud helps shape and transform Telecom Network deployment and monetization models” and live on the edge at the Demo Showcase. 
• And for Distributed Cloud, make sure you attend “Running AI at the edge to deliver modern customer experiences” and “Mind the air gap: How cloud is addressing today’s sovereignty needs”, or visit our area at the Demo Showcase.

#5 — Save money and help meet sustainability ambitions

Everyone knows that AI can help you do more, faster, but did you know that our AI-assisted recommendations and cost optimization tools can help you save money and  to plan for strong financial resiliency? Take control of your cloud spending and optimize costs through APIs, Cloud Scheduler, and with Committed Use Discounts (CUDs). Complementary to these cost optimization capabilities, we’ve also built a collection of tools to help you accurately report on the carbon emissions associated with your Google Cloud usage and take action to reduce your carbon footprint and costs. Looking to learn more at Next ‘23, here’s what you need to explore:

• For sustainability, register for our “GreenOps: Drive carbon and cost efficiencies with a new wave of developer tools” breakout session.
• And for cost savings, check out “Creating a FinOps culture change through cloud automation” and “Unlock cloud value for everyone with Google Cloud FinOps tools”, and also visit our cost optimization area at the Demo Showcase.

So, what do you think: are any of those challenges on your plate right now? If they are, we hope you’ll join us at Next ‘23 starting on August 29th, so that we can show you how we live up to your motto: your cloud, your way. See you soon!

Introduction

In my previous post, I talked about how you can use a parent workflow to execute child workflows in parallel for faster overall processing time and easier detection of errors. Another useful pattern is to use a Cloud Tasks queue to create Workflows executions and that’s the topic of this post.

When your application experiences a sudden surge of traffic, it’s natural to want to handle the increased load by creating a high number of concurrent workflow executions. However, Google Cloud’s Workflows enforces quotas to prevent abuse and ensure fair resource allocation. These quotas limit the maximum number of concurrent workflow executions per region, per project, for example, Workflows currently enforces a maximum of 2000 concurrent executions by default. Once this limit is reached, any new executions beyond the quota will fail with an HTTP 429 error.

A Cloud Tasks queue can help. Rather than creating Workflow executions directly, you can add Workflows execution tasks to the Cloud Tasks queue and let Cloud Tasks drain the queue at a rate that you define. This allows for better utilization of your workflow quota and ensures the smooth execution of workflows.

Let’s dive into how to set this up. 

Create a Cloud Tasks queue

We’ll start by creating a Cloud Tasks queue. The Cloud Tasks queue acts as a buffer between the parent workflow and the child workflows, allowing us to regulate the rate of executions.

Create the Cloud Tasks queue (initially with no dispatch rate limits) with the desired name and location:

QUEUE=queue-workflow-child
LOCATION=us-central1

gcloud tasks queues create $QUEUE --location=$LOCATION

Now that we have our queue in place, let’s proceed to set up the child workflow.

Create and deploy a child workflow

The child workflow performs a specific task and returns a result to the parent workflow.

Create workflow-child.yaml to define the child workflow:

main:

  params: [args]

  steps:

    - init:

        assign:

          - iteration: ${args.iteration}

    - wait:

        call: sys.sleep

        args:

            seconds: 10

    - return_message:

        return: ${"Hello world" + iteration}

In this example, the child workflow receives an iteration argument from the parent workflow, simulates work by waiting for 10 seconds, and returns a string as the result.

Deploy the child workflow:

gcloud workflows deploy workflow-child --source=workflow-child.yaml --location=$LOCATION

Create and deploy a parent workflow

Next, create a parent workflow in workflow-parent.yaml.

The workflow assigns some constants first. Note that it’s referring to the child workflow and the queue name between the parent and child workflows:

main:
  steps:
    - init:
        assign:
          - project_id: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
          - project_number: ${sys.get_env("GOOGLE_CLOUD_PROJECT_NUMBER")}
          - location: ${sys.get_env("GOOGLE_CLOUD_LOCATION")}
          - workflow_child_name: "workflow-child"
          - queue_name: "queue-workflow-child"

In the next step, Workflows creates and adds a high number of tasks (whose body is an HTTP request to execute the child workflow) to the Cloud Tasks queue:

- enqueue_tasks_to_execute_child_workflow:
        for:
          value: iteration
          range: [1, 100]
          steps:
              - iterate:
                  assign:
                    - data:
                        iteration: ${iteration}
                    - exec:
                        # Need to wrap into argument for Workflows args.
                        argument: ${json.encode_to_string(data)}
              - create_task_to_execute_child_workflow:
                  call: googleapis.cloudtasks.v2.projects.locations.queues.tasks.create
                  args:
                      parent: ${"projects/" + project_id + "/locations/" + location + "/queues/" + queue_name}
                      body:
                        task:
                          httpRequest:
                            body: ${base64.encode(json.encode(exec))}
                            url: ${"https://workflowexecutions.googleapis.com/v1/projects/" + project_id + "/locations/" + location + "/workflows/" + workflow_child_name + "/executions"}
                            oauthToken:
                              serviceAccountEmail: ${project_number + "-compute@developer.gserviceaccount.com"}

Note that task creation is a non-blocking call in Workflows. Cloud Tasks takes care of running those tasks to execute child workflows asynchronously.

Deploy the parent workflow:

gcloud workflows deploy workflow-parent --source=workflow-parent.yaml --location=$LOCATION

Execute the parent workflow with no dispatch rate limits

Time to execute the parent workflow:

gcloud workflows run workflow-parent --location=$LOCATION

As the parent workflow is running, you can see parallel executions of the child workflow, all executed roughly around the same:

In this case, 100 executions is a well under the concurrency limit for Workflows. Quota issues may arise if you submit 1000s of executions all at once. This is when Cloud Tasks queue and its rate limits become useful.

Execute the parent workflow with dispatch rate limits

Let’s now apply a rate limit to the Cloud Tasks queue. In this case, 1 dispatch per second:

gcloud tasks queues update $QUEUE --max-dispatches-per-second=1 --location=$LOCATION

Execute the parent workflow again:

gcloud workflows run workflow-parent --location=$LOCATION

This time, you see a more smooth execution rate (1 execution request per second):

Summary

By introducing a Cloud Tasks queue before executing a workflow and playing with different dispatch rates and concurrency settings, you can better utilize your Workflows quota and stay below the limits without triggering unnecessary quota related failures. 

Check out the Buffer HTTP requests with Cloud Tasks codelab, if you want to get more hands-on experience with Cloud Tasks. As always, feel free to contact me on Twitter @meteatamel for any questions or feedback.

The concept of “shifting left” has been widely promoted in the software development lifecycle. The concept is that introducing security earlier, or leftwards, in the development process will lead to fewer software-related security defects later, or rightwards, in production.

Shifting cloud security left can help identify potential misconfigurations earlier in the development cycle, which if unresolved can lead to security defects. Catching those misconfigurations early can improve the security posture of production deployments.

Why shifting security left matters

Google’s DevOps Research and Assessment (DORA) highlights the importance of integrating security into DevOps in the 2016 State of DevOps Report. The report discussed the placement of security testing in the software development lifecycle. The survey found that most security testing and tool usage happened after the development of a release, rather than continuously throughout the development lifecycle. This led to increased costs and friction because remediating problems found in testing may involve big architectural changes and additional integration testing, as shown in Figure 1. For example, security defects in production can lead to GDPR violations, which can carry fines up to 4% of global annual revenue.

By inserting security testing into the development phase, we can identify security defects earlier and perform the appropriate remediation sooner. This results in fewer defects post-production and reduces remediation efforts and architectural changes. Figure 2 shows us that integrating security earlier in the SDLC results in overall decreases in security defects and associated remediation costs.

The 2021 State of DevOps Report expands the work of the 2016 report and advocates for integrating automated testing throughout the software development lifecycle. Automated testing is useful for continuously testing development code without the need for additional skills or intervention by the developer. Developers can continue to iterate quickly while other stakeholders can be confident that common defects are being identified and remediated.

From code to cloud

The DORA findings with regard to code security can also be applied to cloud infrastructure security. As more organizations deploy their workloads to the cloud, it’s important to test the security and configurations of cloud infrastructure. Misconfigurations in cloud resources can lead toward security incidents that could lead to data theft. Examples of such misconfigurations include overly permissive firewall rules, public IP addresses for VMs, or excessive Identity and Access Management (IAM) permissions on service accounts and storage buckets.

We can and should leverage different Google Cloud services to identify these misconfigurations early in the development process and prevent such errors from emerging in production to reduce the costs of future remediation, potential legal fines, and compromised customer trust.

The key tools in our toolshed are Security Command Center and Cloud Build. Security Command Center provides visibility into misconfigurations, vulnerabilities, and threats within a Google Cloud organization. This information is critical when protecting your cloud infrastructure (such as virtual machines, containers, web applications) against threats, or identifying potential gaps from compliance frameworks (such as CIS Benchmarks, PCI-DSS, NIST 800-53, or ISO 27001.

Security Command Center further supports shifting security left by allowing visibility of security findings at the cloud project level for individual developers, while still allowing global visibility for Security Operations. Cloud Build provides for the creation of cloud-native CI/CD pipelines. You can insert custom health checks into a pipeline to evaluate certain conditions (such as security metrics) and fail the pipeline when irregularities are detected. We will now explore two use cases that take advantage of these tools.

Security Health Checker

Security Health Checker continuously monitors the security health of a Google Cloud project and promptly notifies project members of security findings. Figure 3 shows developers interacting with a Google Cloud environment with network, compute, and database components. Security Command Center is configured to monitor the health of the project.

When Security Command Center identifies findings, it sends them to a Cloud Pub/Sub topic. A Cloud Function then takes the findings published to that topic and sends them to a Slack channel monitored by infrastructure developers. Just like a spell checker providing quick feedback on misspellings, Security Health Checker provides prompt feedback on security misconfigurations in a Google Cloud project that could lead to deployment failures or post-production compromises. No additional effort is required on the part of developers.

Security Pipeline Checker

In addition to using Security Command Center for timely notification of security concerns during the development process, we can also integrate security checks into the CI/CD pipeline by using Security Command Center along with Cloud Build as shown in Figure 4.

The pipeline begins with a developer checking code into a git repository. This repository is mirrored to Cloud Source Repositories. A build trigger will begin the build process. The build pipeline will include a short waiting period of a few minutes to give Security Command Center a chance to identify security vulnerabilities. A brief delay may appear undesirable at first, but the analysis that takes place during that interval can result in the reduction of security defects post-production.

At the end of the waiting period, a Cloud Function serving as a Security Health Checker will evaluate the findings from Security Command Center (Connector 1 in Figure 4). If the validator determines that unacceptable security findings exist, the validator will inject a failure indication into the pipeline to terminate the build process (Connector 2 in Figure 4). Developers have visibility into the failure triggers and remediate them before successfully deploying code to production. This is in contrast to the findings in the 2016 State of DevOps Report wherein organizations that didn’t integrate security into their DevOps processes spent 50% more time remediating security issues than those who “shifted left” on security.

Closing thoughts

DORA’s 2016 State of DevOps report called out the need for “shifting left” with security, introducing security earlier in the development process to identify security vulnerabilities early to reduce mitigation efforts post-production. The report also advocated for automated testing throughout the software development lifecycle.

We looked at two ways of achieving these objectives in Google Cloud. The Security Health Checker provides feedback to developers using Security Command Center and Slack to notify developers of security findings as they pursue their development activities. The Security Pipeline Checker uses Security Command Center as part of a Cloud Build pipeline to terminate a build pipeline if vulnerabilities are identified during the build process. To implement the Security Heath Checker and the Security Pipeline Checker, check out the GitHub repository. We hope these examples will help you to “shift left” using Google Cloud services. Happy coding!

This article was co-authored with Jason Bisson, Bakh Inamov, Jeff Levne, Lanre Ogunmola, Luis Urena, and Holly Willey, Security & Compliance Specialists at Google Cloud.

On April 6th, 2022, Google Cloud established a new partnership with CAST, to help accelerate the migration and application modernization programs of customers worldwide, complementing the Google capabilities already available through the Google Cloud Application Modernization Program (CAMP).

Application Rationalization (App Rat) is the first step towards a cloud adoption or migration journey, through which you go over the application inventory to determine which applications should be Retired, Retained, Refactored, Replatformed, or Reimagined.

Why is this important to you?

Have the majority of your in-house applications still not moved to the cloud? How much time does your development team spend on support (bug fix, tickets, etc.) versus feature(s) development? Have Infrastructure/Platform dependencies ever delayed product rollout? Would an auto-scalable, managed cloud, increase stakeholder buy-in?

Can Google simplify this journey?

Google Cloud Application Modernization Program (CAMP) has been designed as an end-to-end framework to help guide organizations through their modernization journey by assessing where they are today, and provide a path forward. When it comes to App Rationalization, this depends on what your role is.

Step 1 (Assess): Who is the target audience? The Platform team (or) the Application team?

This determines what kind of challenges we are trying to solve. For e.g. the centralized platform team wants to set some guardrails on how the App teams deploy their apps. Streamlining this would allow the platform team to mature themselves into the SRE territory. The application team, on the other hand, loves flexibility, and the ability to perform Continuous Delivery.

These examples are only the tip of the iceberg. Most of the enterprise customers have a majority of their applications in the legacy world. Unless we move those business critical applications to the cloud, it’s impossible to mature as an enterprise. For more information, check State of DevOps 2021 report.

Step 2 (Analyze): Google Cloud offers the tooling and the framework to analyze your legacy applications.

Platform Owner (persona), usually have very little information on which workloads are a good fit for modernization.

Google’s StratoZone® SaaS platform provides customers with a data-driven cloud decision framework. The StratoProbe® Data Collector Application delivers the ability to easily deploy and scale the discovery of a customer’s IT environment for Private, Public, or Hybrid-cloud planning. To ease and accelerate the VM migration journey, Google Cloud offers assistance and guidance in making the right decisions when deciding to go to cloud.

Google’s mFit aims at unblocking customers in their transformation by providing workload selection for successful on-boarding, at scale, to Anthos, GKE and Cloud Run , in both pre-sales (e.g. proof-of-concept/proof-of-value) and post-sales (e.g. pilot and at scale execution) scenarios.

App and/or Business Owners (persona), get involved in a 1-week workshop, using CAST Highlight, which would provide rapid portfolio assessment through automated source code analysis for Cloud Readiness, Open Source risks, Resiliency, and Agility.

Step 3 (Plan & execute): Each organization is different. Some may follow the “Migration Factory” approach, and some may follow “Modernization Factory”, and some may follow both. Irrespective of which approach you choose to follow, it is important to plan just enough, so that you can start your execution. Ensure to set the OKRs, that would help with the right measurements, before you start the execution. The actual learning from the execution helps the team(s) to learn more about the cloud migration process, and refine it based on their organization.

Using CAST Highlight in the assessment step previously, we get the recommendation for the analyzed applications. From there, for certain workloads, we can use Migrate to Containers, to automate the containerization of suitable workloads. However, there are certain applications that require manual code changes. You have a few options for that,

• Our experts can help you get started.
• Our partners can help you

Step 4 (Measure & reiterate): Measure the progress using the predefined metrics in the previous step. Celebrate the wins. Consistently share the learnings and best practices with the developer community. Pick the next challenge

Take the next step

Tell us what you’re solving for. A Google Cloud expert will help you find the best solution.

In modern software development, automating delivery using Continuous Integration and Continuous Deployment (CI/CD) pipelines draws parallels to automotive assembly lines that doubled the production while cutting down costs by 65%. According to a recent report from Postman, over 51% of respondents indicated that their organizations devote more than half of their development efforts to APIs. APIs are a big part of development, so let’s explore why you should integrate them into your CI/CD pipelines. We will also share best practices and tools for integrating Apigee within your organization’s CI/CD processes.

4 reasons to automate your API delivery with CI/CD pipelines

Apigee is a feature-rich API management platform that provides developers with the necessary tools to build, secure, manage, and publish APIs. But what if you want to automate the process of deploying your APIs to Apigee? That’s where CI/CD comes in. By incorporating Apigee into your CI/CD pipeline, you can automate API deployment, promote consistency across environments, and monitor API performance in real-time. Four of these benefits include:

• Cut time to market by and respond faster to customer demands by automating API deployments.
• Catch defects earlier and improve API security by automating the process of testing and securing APIs.
• Slash costs by saving on staffing, tools, and infrastructure required to deploy and manage APIs.
• Improve visibility and compliance by tracking and auditing API usage.

Key tools and useful tips to effectively automate API delivery and management

Integrating API delivery into CI/CD pipelines using products like Cloud Build streamlines the development process. For example, a developer building an application on Google Cloud can deliver APIs side by side with other workloads in tools such as Cloud Run, Google Kubernetes Engine (GKE), Cloud Functions, and  App Engine.

Operational automation can include a list of seemingly endless aspects of the development process. But at a high-level, the key components of an effective CI/CD pipeline for API management  include:

1. Building and testing API proxies

• If you are new to Apigee, utilize the comprehensive visual tools in the console to build and deploy API proxies using a convenient drag and drop interface. You can elevate their API proxy development by leveraging the VS Code extension and Apigee Emulator. This local setup enables you to use auto-complete features along with local proxy deployment, testing, and seamless code commit to trigger the pipeline for further deployment across Apigee environments.
• Useful tip: Maximize the utility of Apigee, use the Debug tool to inspect every detail of an API transaction. Lastly, remember to export your proxy from the Apigee console and commit it to your source repository. With these best practices in hand, you’re all set to make the most of your Apigee journey.

2. Store and version your API code: 

• Ensure robust source code management – foundation of every CI/CD pipeline – to easily track, and manage changes. Use Cloud Source Repositories, a fully managed Git repository for seamless integration with other GCP development (or) leverage common tools like GitHub, GitLab, BitBucket and many more depending on your organization’s approach
• Useful tip: Employing the right branching strategy helps reduce complexity and keeps delivery lean. Check out this community post for different branching strategies and choose the right one for your use case. Ensure frequent commits and merges to your source code to keep your codebase healthy and up-to-date. Regular code reviews also help refine your code and create quality checkpoints.

3. Ensure code quality with static code analysis:

• Regular static code analysis can help you to improve the quality of your code by detecting potential errors and security vulnerabilities. It can also help you to promote code standardization by ensuring that your code follows a consistent style. For static code analysis you can use apigeelint (for analyzing Apigee bundles), JSHint and ESLint (for JavaScript analysis), Checkstyle and PMD (for Java analysis), or SonarQube (for multi-language support)
• Useful tip: Integrate the tool with your code editor so that you can see the results of the analysis as you write code. Define quality gates/thresholds and run the tool as part of your build pipeline. Mark the build as failed if it does not meet the thresholds.

4. Ensure code resilience with unit testing and Code coverage: 

• Unit tests focus on individual units of code, such as methods or classes. They help to ensure that each unit of code works as expected. Code coverage measures the percentage of code that is covered by unit tests. A high code coverage percentage indicates that more of your code is being tested, which can help to reduce the risk of errors. You can use these tools for unit testing and code coverage: Mocha and Chai (for JavaScript), JUnit (for Java), Cobertura and Istanbul (nyc) (for code coverage)
• Useful tip: Write unit tests for all of your code. This includes both new code and existing code. Run unit tests during the build process. This will help to ensure that your code is always passing unit tests before it is deployed. Set coverage thresholds and mark the build as failed if it does not meet the thresholds. This will help to ensure that your code is sufficiently covered by unit tests.

5. Configure, Package and Deploy your code:

• Creating a successful API deployment is like constructing a sturdy building. You need a strong blueprint (your Apigee code) that has been carefully planned, packaged into a deployable format (a zip file), and then implemented (imported into Apigee and deployed to an Apigee environment). During the packaging phase, the blueprint is detailed with metadata and manifest, similar to labeling and preparing architectural plans for construction. Moreover, all your Apigee configurations, except sensitive info, can be integrated into your blueprint, ready to be brought to life with the right tools. In terms of tooling, you can choose from a variety of open-source options that are built on Apigee APIs. Some of the commonly utilized ones are Apigee Deploy Maven plugin, apigee cli, apigee-sackmesser, and custom scripts using the Apigee APIs.
• Useful tip: Use an artifact system to store these bundles. This will make it easy to manage and track your bundles. Maintain all the necessary configurations like Target server, Key Value Map, etc as part of the source code repo. This will make it easier to deploy your code to different environments. Use the pipeline and the source code to promote the proxies from lower environments to production. This will help you to ensure that your code is always up-to-date in production.

6. Verify the changes with Functional or integration testing:

• Consider integration testing as a rigorous dress rehearsal for your API’s debut performance. It’s your chance to verify if your API plays its part flawlessly under various scenarios, including when it has to share the stage with third-party systems. To ensure the API is working as expected, you have some powerful tools at your disposal such as Apickli (based on cucumber.js), Postman, and JUnit
• Useful tip: Manage these tests as part of the source code and run different test suites based on the environment deploying to. This will make it easy to track and manage your tests. Run these tests right after the deployment and mark the build as failed if it does not meet the threshold. This will help you to identify and fix any issues that may have been introduced during the deployment. Create rollout plans when the functional tests fail by rolling out to the previous working/stable version. This will help you to minimize the impact of any issues that may have been introduced during the deployment.

Additionally, here are some optional trail markers you can consider on your journey to perfecting your pipeline:

1. Testing Your API’s Endurance: Running performance tests ensures your API can withstand the long haul.
2. Clear and Accessible Documentation: Keep your developer portal up-to-date with the latest API documentation. Tools like the Apigee Smartdocs Maven plugin can make this a breeze, particularly with the Drupal developer portal.

Here is a typical pipeline example with a comprehensive reference implementation we see with most of our customers. It triggers when the developer commits the code to the repo. The pipeline can be executed by any CI/CD platform like Cloud Build.

Get started today

Why wait? Kickstart your Apigee journey today directly from the console or evaluate it for free. Leverage our Accelerators to jumpstart your development using examples or advanced technical guidance. Should you have any questions or need support along the way, our Apigee Community is teeming with experts ready to lend a hand.