<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Getting_Started_with_Terraform_on_SAP_BTP_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-02-18T09:44:29.000Z

Handing Over to the Development Team

Lesson Content

Getting Started with Terraform on SAP BTP

SAP_MOOC_terra1_unit5_lesson2_DEVTEAM_Video.mp4

Hi and welcome to Unit 4 Lesson 2. Here we will be handing over our Terraform script to the development team. We are now in the second step to apply some advanced Terraform concepts in our journey. We will take everything that we have created so far and prepare it for hand over to the development teams of our target persona. So in this lesson we will learn about options to enable a sales service to run Terraform scripts. We will use outputs of the Terraform configurations for that purpose, and you will get an outlook on how the output can be integrated into existing toolings like a CICD pipeline, for example. So, but before going into the details, let's maybe do a quick recap on the outputs principle. As we learned, the outputs are something very similar to return values in other programming languages. And these outputs are defined in output blocks within our Terraform configuration. Now the question is, how do the outputs actually help us to hand over the infrastructure to the development team of our target persona? Christian. Let us first take one step back and ask one question. Why are we doing all that stuff? The infrastructure and the resources within are provided to enable our application development teams on SAP BTP. But after provisioning the infrastructure, how does the development team learn about the available resources? Wouldn't it be great to provide the information like links to cloud foundry spaces or the business application studio directly to the teams to give them a kickstart once the infrastructure is there? I assume that would be great, right? So let us refine the setup a bit to achieve that goal. And with that, let's head over to the Hands on, here we will enhance the Terraform configuration with reasonable outputs to provide information to the development team and then look at the option how to integrate this information with other tools like GitHub. Okay, now let's get into our README file for Unit 4 Lesson 2, where we are seeing that we want to hand over now actually two information. information pieces to our development team. On the one hand side, we want to add the URL to the subaccount to the team, as well as the URL to the Cloud Foundry space. So let's take one step after the other. So we need to actually provide, we start with the subaccount URL. And you see here in this row that the sub-account URL is is consisting of two pieces, actually. So the global account ID and a subaccount ID that we need to add the complete URL. So meaning that we need to first find out how to get those two IDs. And for that, we can use a data resource called BTP Global Account. Exactly. So that's, again, something that you find, of course, in the documentation. So as we looked in a previous lesson for the data source for service plans, we can now check the BTP Global account. There is a data source for that one, which returns, of course, also the technical ID. That's what we need. And that's what we need. Subaccount ID, that's something that we already have, right? Because we created the sub -account in our Terraform script. So let's then create that resource in our main TF file for BTP. So let's switch back. Now, be aware you have now to go into the BTP directory and there into the main TF file. Otherwise, this won't work. So let's add the data source here for the global account. And then as we already laid out outputs are kind of the magic glue that allows you to add this information for the user in a very convenient way. So what we have to do is now to construct the URL via the data that we have to do. have and add that as an output to our terraform script right so let's copy this and now move over to the outputs tf file for the BTP piece and here we see exactly how we are building up the URL with the prefix and then we are adding from the data source that we created data dot BTP global account dot this dot ID and then at the that's the global account ID and then for the subaccount ID like Chris had already mentioned we already have that that's BTP sub account project subaccount ID so that's how we put this together and I think that's mainly it right so that's it yeah so we have everything in the main Tf file we have the data we have the resource we have it in the output so let's switch now to the terminal here into the BTP folder important switch to the BTP folder otherwise you might be surprised that things don't work. And then we do the Terraform FMT. All good. Let's see if we brought in some mistakes. Of course not everything successfully configured. Then we do a Terraform plan. Unit 4-2. And... And let's go. Let's see what happens. So it's fetching the current state. of everything. No, it shouldn't change anything in the resource configuration or in the provisioning but it should update the output variables. Now, refreshing state always takes a bit on BTP but as you can see, there is. There are no changes to the configuration, but there are changes to the output. And in order to manifest that, because we trusted the planning, we will now do the applying so that we can access the information via Terraform output. And here we go. We have this app account URL. Should we give it a try? Just click on it. We click on it. We open it. And drum roll, we will now hopefully see our sub account. That worked. So let's continue. Yeah, we have now the URL to the sub account. Now we need to have the URL to the Cloud Foundry Space, which works a similar way. We see it here. That's the pattern for the Cloud Foundry Space. We see a little bit more ID limbo because we need to add the org ID as well as the space ID. And now we are playing the same principle we have used before. Yeah, so I would say we reuse this lengthy first part because we already We have the subaccount URL. So we just add that as a variable and put that in from the output that we got before. So we create a new variable called subaccount URL. Now again we switch over to the Cloud Foundry folder. We go to the variables.tf in that folder and add this variable. And I mean we can directly add it also to the... Terraform TFVARS, but... Yeah, let's do that. before we forget it so and we say that's empty empty at the moment but we can take this URL the one from the previous run yeah so now really make sure that you are in the right files and you have one yeah perfect that's definitely not short and now save it the file perfect so we have that one then we have the output we want to use in the for the cloud foundry space URL exactly so we have to construct that again yeah so we copy it we go to the cloud to the cloud foundry folder and then we don't have outputs we need to create outputs a TF file yep let's do that and in that one we just paste this output definition and we see there we are constructing it with the variable subaccount URL and then the other variables from the org ID and the cloud foundry space ID so and we save it the org ID I mean that that's worth to mention that's something that we already have within our variables from the from the first from the first one so that's that little friend here and we also got that from provisioning the environment via BTP and we should see it in the Terraform TFVARS file as well from the Cloud Foundry. Yeah, so I will now close a few files here because otherwise it's getting confused. It's getting busy. So here we have it. In line 2, CF org ID. Okay, so let's clear. Let's switch first the folder to the Cloud Foundry folder. I mean you can clear and switch then, but don't forget to switch. That's important. So we're not there now and now we do a Terraform FMT. Yeah, bad Christian didn't form it correctly. Okay, so then we do a Terraform validate. And this will go wrong because you didn't type Terraform with 2Rs. Also happens sometimes. But the configuration is valid. Looks good. Then we do again a Terraform plan. For unit... For the unit... For 2. Yeah. And again, we see there are changes to the output. I mean, there is now output, because before there was none. Let's bring that into the state. Terraform Apply. And now let's also open that to URL. We click on it, we open it. Let's see if we get to the space, to the Cloud Foundry space. Yes, there it is. Here we go. It's in our trial, in our subaccount, and there is the space. Now, you can say, of course, cool. But there must be something cooler to do this handover. This handover is now not really the end. So we have now the output variables. We have everything in place to enable folks to do self-service. Now, what is not in scope of the course is to enhance the CICD pipeline and bring that to life. Nevertheless, we want to show you how this could look like when you leverage GitHub. And this is mentioned here in the bonus section on GitHub in this ReadMe file. And you also find the information how to do that, what files you need to add in the repository. I think what we can do now is maybe just do a short demo after you went through this bonus exercise if you want. because it's you need some more knowledge how to do this which is explained here we have taken now a separate trial account that we want to use for that purpose right yeah so that that one is completely empty I can refresh that one so and you will now show how to fill this now with a github with a flow yeah we have the same multi-step deployment in place and we say hey usual What would you want to have as a development team? Well, I want to open an issue and I want to say, hey, I want to request a sub-account for my project. So let's get started. I want a new dev subaccount with two Cs. Then I take a project name, so let's say a Terraform MOOC. Terraform MOOC, that sounds good to me. Then we have a cost center. We say it's one, two, three, four, five, because we're really creative. We have a subaccount region, US10. We say subaccount stage, yeah, it's dev. And space manager, that should be me. And that's all that I want to hand over to my platform team because that's what I know I, as a development team, shouldn't care about the infrastructure. Yeah. So I will submit that issue. And now I'm now the platform team, right? Who actually is seeing that there is an issue that was just opened up. I can see it here. Well, I mean, you see the issue, but you also get a notification that an action got kicked off. Action is a CICD workflow. Just think about it as an automated workflow that does something with respect to the telephone. But it is still on waiting. It is waiting, obviously. Which is good because we don't want people to do this immediately, but actually we want actually to also review, right? Exactly. So usually it wouldn't be the same person that is issuing the request and then doing the review, but... For our case, it's fine. Don't be too picky here. Looks good to me. And we approve and deploy the stuff and things will now kick off. So the workflow will start. And while this is running and setting up everything on BTP, there is no hidden magic behind that. So you also have that in the repository. It's just a YAML file and who doesn't like YAML which executes the steps that we just saw. We, as you can think, extract the information from the issue so that we get the cost center and the stage, which we need for labeling the subaccount. If you remember one of the first lessons. And then we set up Terraform. We execute Terraform. So there's a lot of things to do, of course, to fill in the variables for BTP, for Cloud Foundry. And at the end of the day, we want to update our issue because the development team wants to have the URLs, right? So let's head back to the actions. It's still running. So it takes a bit. But maybe we can already have a look in the global account here. I guess that the sub account has already been created. There it is. Sub account is already there. We see Cloud Foundry has also been set up. And the space has been set up. So I think it should be, yeah. Yes, it's green. So that's cool. Now, as a development team, I would say, yeah, cool, but I don't care. I want to have the information that I need. And as you saw, we updated the issue. So the sub-account for the project has been created successfully, hooray, and you have all the URLs that you need in order to interact or to directly jump to the subaccount, to the space, and you also have the CF API URL, for example, using the CFCLI. So I think that's what you would like to see, and that's what we wanted to present in this demo that with the Terraform configuration that we set up we enable something like this Yeah and then that's now we can also see how the this principle of outputs can be used here quite nicely because what you are doing in the flow is actually fetching the information from this outputs file and then pasting it here into an issue comment which provides in every information that the team then needs. So I think we did a fantastic job. Absolutely. And hope you liked it. And now we are back. What a ride. Let's put together our key takeaways. We saw that Terraform can enable development teams to easily take over infrastructure from platform teams. Such platform teams should keep in mind that their main purpose is to enable application development to ensure that information is provided properly. For that purpose, the Terraform output values provide a very solid foundation. They enable a handover of information from a platform team to a development team. And with that, thank you very much for listening and looking forward to our next lesson. Bye-bye.