Back in April 2017 AWS released CodeStar, a cloud service designed to make it easier to develop, build, and deploy applications on AWS by simplifying the setup of your entire development project. This sounds to me a lot like a DevOps dream.
AWS CodeStar is used as a bundle service, because it uses CodeCommit, CodeBuild, CodePipeline, CodeDeploy, Lambda, EC2, Elastic Beanstalk, CloudFormation, and Cloud9.
Let me guide you step by step on setting up AWS CodeStar.
First thing you are presented with are multiple templates that will help you get started with Web Application or Web Service. Within these templates you are presented with popular programming languages like C#, GO, HTML 5, Java, Node.js, PHP, Python, and Ruby. Each of the programming languages can be launched into other AWS services such as EC2, Elastic Beanstalk, and AWS Lambda. For this article, I have decided to create HTML 5 with the only AWS service provided for this language is EC2.
Once you decide your programming language and AWS service you are presented with the Project details screen. Within this screen you are able to pick your project name, and the repository you would like to use. I have decided to go with AWS CodeCommit.
The repository part is one limitation that I noticed right away. You only get two repository options AWS CodeCommit or GitHub, but what about Bitbucket, GitLab or other Git repositories. Well that is when it becomes a little more difficult to setup, because it will require you to setup a Github hook to an Amazon API Gateway to AWS Lambda that pushes your code to Amazon S3.
Now that we have named the project and picked the repository we get presented with a pipeline review. We see that AWS CodeCommit will be the Source, Build and Test currently have nothing, Deploy is using AWS CodeDeploy, and for Monitoring it will use Amazon CloudWatch.
Since I picked EC2, I am able to pick the EC2 configuration. This allows me to pick the instance type, VPC, and subnet. What I do not like about this is the security side of it. CodeStar assumes that I have already configured the VPC and Subnet.
Once you have configured the settings that were presented to you it will either bring you to the next create project step or if an EC2 was needed, it will ask you for an Amazon EC2 Key Pair. Which could be another limitation, because you have to have one created, but you can also create it in another window and refresh.
Maybe you have already been presented with this, but after the steps above you are presented with connectivity. You are allowed to use multiple tools outside of the ones listed, but the following are just the most common used, besides the AWS Cloud9 IDE tool. If you did pick GitHub it would ask you for integration with GitHub, but since I picked CodeCommit it provides me with an HTTPS/SSH connection string. HTTPS has been known to have issues pushing to Git well SSH hasn’t. It really depends on your preference and the size of the push.
I have decided to pick the AWS Cloud9 IDE Tool. Depending on the tool you pick it will explain how to get your CodeCommit linked up to the tool of choice. Once done the creation of a CodeStar project is finished and the real fun starts.
You can skip this section about me explaining AWS Cloud9 if you decide not to use that IDE tool, but it is something that you should definitely consider.
What is AWS Cloud9?
Back in 2016 AWS acquired a company called Cloud9. This company focused on created an integrated development environment for web and mobile developers to collaborate together. It wasn’t until re:Invent 2017 that AWS announced AWS Cloud9.
The one major downside of Cloud9 is that it requires EC2 instances to run it. Now depending on your coding structure or how large of an instance you want to create AWS Cloud9 could cost you less than $2 per month or more.
You can also go into the advanced setting and change the network, tag, and cost-saving settings. The cost-saving settings (hibernation) is a really cool feature, because it allows the AWS Cloud9 EC2 instance to be shutdown an intervals of 30 minutes.
For me the key purpose of using Cloud9 comes down to what is my production system is going to use. You will probably be using an EC2 environment that is based on the Amazon Machine Image (AMI) with the instance type of your choice. Most of the AMI will have your AWS CLI, git, Python, Java or even another programming language installed.
Limitations of AWS Cloud9
- Limited Live debugging
- No offline functionality
- Limited integrations with other AWS Services within Cloud9 console
Finishing up CodeStar
Now you have reached the final screen, or what is known in CodeStar the dashboard.The dashboard allows you to drag-and-drop the multiple sections around. The sections are as followed: project wiki section, CloudWatch metrics, API endpoint (not if you used EC2), and git history from CodeCommit or GitHub. If it is integrated with JIRA or GitHub, you are able to add issue tracking section.
Congratulations you have now created your first CodeStar project.
Limitations of CodeStar
I did have an issue of taking my code from a my do it yourself pipeline to CodeStar. The code wouldn’t compile within CodeStar, but did just find in CodeBuild. Not sure if this an AMI issue, but would need a deeper debugging.
- Max of 10 projects per user
- No Custom Project templates
- No Integration with BitBucket
- No API endpoint for EC2 instances
- Slow when deploying
Thanks for reading this (extra long) I hope you come out learning more about AWS CodeStar and AWS Cloud9. Stay tuned for the next article about setting up HTML 5. If you’d like to know more about using CodeStar, please contact us here.