In the last few issues of this series, the team has done the following:
Introducing the Thrashing Code Team & Projects - Know who’s working on what and what the projects are.
“Getting Started, Kanban & First Steps for a Sharing App“ - Getting the kanban put together and the team involved.
“Starting a Basic Loopback API & Continuous Integration“ - Getting the skeleton of the API application setup and the continuous integration services running.
In this issue of the series Keartida is continuing with setup and configuration of the next step, getting to a basic continuous delivery of services with a basic AWS Elastic Beanstalk setup.
AWS Elastic Beanstalk
Let’s talk a little bit about the solutions and working with teams in the solutions before diving into Keartida’s efforts. With each of the SaaS solutions that I’ve pointed out in the last couple of entries each has a specific connection, integration, or reliance on Github. This is, of course perfect so that each part works seamlessly together. AWS has it’s own user management system which also needs to be taken into account.
In CodeShip
It’s easy to add members to a build, which I covered in the previous entry in this series.
In Waffle.io
Waffle.io actually is pretty simple. Simply sign in with your github account and you’re in with an account. But to access certain projects one does have to setup and share the respective kanban boards. The way to do this with Waffle.io is to actually setup users based on the github permissions setup for the user for the particular project.
In AWS
To get users setup in AWS is a little differently. What we need to setup a full build and delivery of the application to AWS is to get the user’s key pair. Let’s take a look at setting up a group and a user in Amazon for this purpose. In this case I am going to create a user for deployment purposes.
On the main AWS Dashboard here, click on Identity & Access Management.
On that page there are several options listed on the left hand side. Click on the Groups and then click on the Create New Group button. After that a wizard will come up.
Enter the group name and click next.
In the Attach Policy step, slect the S3 Full Access and Elastic Beanstalk Full Access policies for this account.
Once the appropriate polices are selected to be attached, click on next step, review and then add the group. Then select the group that was just created and click on the
Once the appropriate user is added, then the parts to wrap up the delivery part of the deployment are all set. Back to what Keartida was working on!
Keartida Deploys coder-swap
First step, Keartida logged into the AWS management console.
Since this is the first Elastic Beanstalk Application that Keartida has deployed, when she clicks on Elastic Beanstalk this screen appears.
From here, she selected Node.js from the drop down and Launch Now. From there a quick wizard appears and let her enter the name of the application and a description.
The application starts being created.
When this is created, the funny thing is the wizard creates a application environment name that causes problems. Keartida and I found this out the hard way, and figured out it is best to just delete this application and create an application and an environment name that works better.
So this time going back she created the application space specifically and went through the various steps to create the application.
Keep clicking next and then…
Now that this is started Keartida logged into CodeShip to setup the final deployment steps for good builds to deploy directly to this beanstalk application.
Once Keartida clicked on Deployment she had options to pick what to deploy to. One of the options is of course Elastic Beanstalk.
The next screen provides options to select branches of the build to deploy with and related information.
Keartida set the key ID and access key. After that she selected the US West 2 data center, the environment and application names, and the S3 bucket. She retrieved the S3 bucket name by navigating into the S3 service and finding the name on the management console as shown.
Once all the parameters were entered Keartida then clicked on create and CodeShip then shows the settings saved as shown below.
After that Keartida created the production branch and pushed it to github. There the build started as shown and began the deploy to AWS Elastic Beanstalk.
Finally once the deployment is detected to have successfully been pushed out and launched in AWS Elastic Beanstalk a message will appear and the build will go green.
Now, after Keartida completed this it’s time to really dive into the workflow of development. Next up, we’ll get a basic site and API services up and running.
