Setting up your development project using AWS Codestar

Background

The focus of the blog post is to create a complete Cloud-based integration environment with minimal effort. The following prerequisites exist:

1. You have already an AWS account, otherwise it is possible to register for the free tier which includes 5 GB S3 storage and 750 hours of EC2 usage.
2. You have an installed version of the AWS cli on your local machine, otherwise this might help you.
3. You configured the AWS cli on your local machine with your AWS account details, otherwise checkout the documentation here.

But what is AWS Codestar? Amazon describes the service in the following way: “AWS CodeStar enables you to quickly develop, build, and deploy applications on AWS. AWS CodeStar provides a unified user interface, enabling you to easily manage your software development activities in one place. With AWS CodeStar, you can set up your entire continuous delivery toolchain in minutes, allowing you to start releasing code faster. AWS CodeStar makes it easy for your whole team to work together securely, allowing you to easily manage access and add owners, contributors, and viewers to your projects. Each AWS CodeStar project comes with a project management dashboard, including an integrated issue tracking capability powered by Atlassian JIRA Software. With the AWS CodeStar project dashboard, you can easily track progress across your entire software development process, from your backlog of work items to teams’ recent code deployments.” This means that AWS Elastic Beanstalk is one of the easiest ways to set up a cloud environment for web applications consisting of load balancers, security groups, EC2 instances and many more components that otherwise would have to be set up separately.

Sounds promising, right? So, let’s start and get our hands dirty.

Setting up a Keypair for EC2 instances

If you have not used EC2 instances (virtual machines) on AWS, you definitely need to setup up a keep pair using the AWS console. All you have to do is to log in to the AWS console, choose the EC2 service and click on Key Pairs under Network & Securityin the navigation on the left hand side of the page. Now, click the button Create KeyPair and give the key pair a name (I named my key pair ec2_pkt) and click Create. The key pair has now been created and is downloaded to your machine for later use.

Creating the development environment

Our environment is created using the AWS console which means that Codestar is chosen as our service and afterwards the Start a project button has to be clicked.

The first choice that has to be made is the runtime environment. Due to the fact that it is a Spring Boot Service, Java Spring / Webservices / AWS Elastic Beanstalk seems the best choice. Then, a code repository needs to be created. Currently, AWS Codestar supports the own AWS Code Commit Repository as well as GitHub. So let’s choose GItHub.

After access from AWS Code Commit (the service which provides the build pipeline) to GitHub is granted, comes a surprise (see below): Only empty repositories are supported.

That is something that needs to be fixed later, so I have to specify a empty repository name, for example PersonServiceAWS and click Next. On the last page we are able to review our choices and then click Create Project when everything is alright.

During creating, we are asked for our key pair that we created as a prerequisite, acknowledge our choice and click Create Project, again. As first time user we are able to specify our display name for the Dashboard and our email address, then we click Next.

Now we are informed that our GitHub repository is about to be created and we click Next.

The only thing is that we have to wait for the project to be setup.

About 30 seconds later, the project setup is ready and the first build is already running.

Changing our GitHub setup in AWS Codestar

When we take a look into the newly created repository, we can see that a Hello World service as well as configuration information for AWS Elastic Beanstalk (.ebextiosions directory) and AWS Code Pipeline (YML and JSON files) have been created.

So, before we can change our GitHub setup in AWS Codestar, it is necessary to copy the newly generated files into our existing GitHub repository.

So inspect our project resources in detail, we can click on the Project entry in the left navigation of the dashboard and see the following type of entries:

By the way, you can query this information using the AWS cli as well with the following command line:

Here we can find the name of our AWS CodePipeline – personservice-Pipeline. Changing our repository name can be done by accessing the pipeline configuration using the AWS cli:

The JSON-based result can now be saved to a file and the line “Repo”: “PersonServiceAWS” can now be changed to “Repo”: “PersonService”. Now, the setup of the pipeline can now be updated using the AWS cli:

using the modified JSON-based output of the get-pipeline command.

So, after we got our GitHub repository updated, we can explore the other options of the dashboard as well.

Now, let’s see if that works. To trigger a new build, the button Release Change can be clicked in the Continuous deployment section of the dashboard.

Yes, it works, but this is only half of the truth. Whenever I commit a change to GitHub, the build does not start automatically. In the dashboard the Source view as well as the Commit History title still points to the old PersonServiceAWS repository. Why is that?

Amazon states here: For an AWS CodeStar project connected to GitHub, disconnect the GitHub repository, and then reconnect the repository to that project, or connect any other repository to that project. You can use the CodePipeline console (not the AWS CodeStar console) to disconnect and reconnect to GitHub in a pipeline’s Source stage. However, if you reconnect the Source stage to a different GitHub repository, in the AWS CodeStar dashboard for the project, the information in the Application endpoints, Commit history, and GitHub Issues tiles might be wrong or out of date. Disconnecting the GitHub repository does not remove that repository’s information from the commit history and GitHub issues tiles in the AWS CodeStar project dashboard. To remove this information, use the GitHub website to disable access to GitHub from the AWS CodeStar project. To revoke access, on the GitHub website, use the Authorized OAuth Apps section of the settings page for your GitHub account profile.

Ok, then that is clear.

The next question will be, how do I access our service over the internet. If we check out the Elastic Beanstalk link in the Project view, we observe the following:

Our AWS Elastic Beanstalk environment does have an application load balancer. So, how do we test our Spring Boot service?

As you can see, the dashboard shows an application endpoint.

Besides the endpoint, the AWS Codestar provides us with an internal mapping from the application’s endpoint port 80 to the default portal of Spring Boot, namely 8080. So our service can be called using the following URL: <application-endpoint>/person/get.

Summary

Using AWS Codestar a development project can be set up very easily. In addition to a build pipeline AWS Codestar supports team access as well as issue management / user tracking capabilities. If you need slightly more flexibility in setting up an environment – your own Cloudformation templates would provide this additional flexibility. As we have seen, don’t use existing repositories while setting up an AWS Codestar projects. Instead create new repositories and copy your existing code to the new location.