# Setting up Cloud9 — Cloud-based integrated development environment (IDE)

15 min readApr 4, 2023

Introduction

This is the 13th week of my DevOps training journey. In the previous GitHub project posting, we have discussed the important roles of DevOps engineer harmonizing the collaboration between Developers and Operators, because both teams share a responsibility to maintain, share and update their codes for developing and testing codes in real time to launch final new production codes for their customers.

Continuous Integration (CI) using a remote GitHub repository

The workflow of maintaining, sharing and updating source code toward production

The above diagram describes how a source code is maintained, shared and updated toward its final production. Software development team (DEV) work in a local repository and system operator team (OPS) in a remote repository.

Initially, the same initial source code is shared and placed in the main branch in the local respository for the DEV team (A) and in the main branch in the remote repository for the OPS team (D). The main branch (D) is also considered as production branch as it releases a final production code to the users. Therefore, the DEV team should not directly upload any code changes to the production branch (D).
The DEV team creates a copy of the source code from (A) to a new development branch in the local repository (B), make changes and tested the updated code there.
Once all the modification and tests are done in (B), the DEV team pushes up the development branch containing the updated code (B) to create a copy of the branch in the remote repository (C).
The DEV team also makes a pull request (PR) to merge the branch © to the production branch(D) in the remote repository. Once the new feature is approved by reviewers (OPS team, stakeholders, etc.), the branch (C) is being merged into the main branch (D).
The DEV team will pull down the production branch (D) to the main branch (A). The update with the new source code for branch A and D is complete up to this point.
Any intermediary development branches should be deleted. The merged development branch (C) and the local development branch (B) should be eliminated.

The characteristics of Cloud9 in AWS service.

Cloud9 is a web browser window-based IDE that provides an optimal code development environment for convenience so that you do not need to worry about installing any necessary applications or components like Git, Python and etc. Everything is all set for use right away!

As the old saying said “Seeing is better than listening”, I will directly share with you how to set up the Cloud9 environment in AWS account.

Setting up Cloud9 Integrated Development Environment.

Prerequisites:

GitHub Access token
Log in as an IAM user with a Administrator Full Access

Step1. Setup a new public remote repository in your GitHub account.

This will enable to do “git push” to GitHub remote respository from your local Cloud9 environment in AWS account.

In Github, click profile icon and Settings on the upper right corner and it will move to a new profile page. On the left side of the screen, click Devloper settings.

Click Tokens(classics) on the left, then click Generate new token arrow and Generate new token (classic) on the right in turn.

Log into your GitHub account.

Check on Repo to allow git push and git pull commands, then click Generate token.

You will see a new screen displaying your Personal access tokens (classic) consisting of a series of random characters. Make sure to save it before leaving the screen. Otherwise, you need to generate a new one from the beginning.

We have an authentication to GitHub using the above token.

Step 2. Create a new remote GitHub repository.

Create Remote repository and main branch

Click “+” sign and New repository.

In Create a new repository, name your repository name.

Then choose the following options below:
— Select Public (create as a public repository)
— Check Add a README file (description for your project)
— Add .gitignore, then type and enter Python not to track changes on Python files.
— Click Create repository and see the following screen:

You do not want any anonymous people to make commits in this repository without your permission.

Click Settings. Leave the default branch main as it is. Click Add branch protection rule

Then the Branch protection rule page will show up.

Designate Branch name pattern name to be the same as the default branch, main.

Check the following protection rules below:

Then Click Create.

Once you reach the repository page below, copy its URL from the web browser. We will register this URL in setting up Cloud9 environment.

You have just created a public remote GitHub repository that strictly requires your approval of merging branches to this main branch there.

Step3. Configuring Cloud9 environment in your AWS account.

The Cloud9 requires an internet access during the configuration process. Please check the following in the VPC dashboard:

make sure to add an internet gateway (IGW).
connect the IGW to your default VPC.
update a route table by including IGW as a destination for internet access (0.0.0.0/0).

## NOTE ##
The creation of Cloud9 environment will be indefinitely stalled without causing a major error due to no access to internet.

In Cloud9 dashboard, click Create environment.

Name your cloud9 environment.

Choose t2.micro free-tier EC2 instance.

Accept the following default settings for Connection, VPC and Subnet.

Click Create to create a new Cloud9 environment.

CloudFormation will be automatically involved in creating stacks to create Cloud9 environment (See below).

In EC2 dashboard, check the EC2 instance running Cloud9.
Then click Actions, Instance settings and Change termination protection in turn.

Check Enable and click Save.

Confirm the termination protection on the EC2 instance running Cloud9 (See the green box message below).

Click Open to open the new Cloud9 environment (cloud9_window_march2023).

Click source control icon (Git icon) on the left side. Click Clone Repositry.

Paste and enter your remote GitHub repository website address in the left upper blank with “Provide repository URL” message.

Confirm the change on the left side indicating your remote GitHub repository name, my-python-repo.

The remote repository is now recognized by Cloud9! :-)

The local Cloud9 repository is synchornized with the remote GitHub repository for the red box items above.

In the terminal window, try to execute git push command. Git command will not work out in your home directory because there is no established Git repository.
In the terminal window, change your current directory to the local git repository, my-python-repo.

You should work in the git repository to execute git command.

Confirm your current branch by looking at the bottom left corner of Cloud9 window. It will indicate main branch (See above).

Click the main branch icon at the bottom left corner of the Cloud9 window. This action will ensure to change your current branch to main branch, which is equivalent to executing “git checkout main” command in the bash terminal window.

Click “+ Create new branch” on the left, then type and enter a new branch name in the upper left blank. This action is equivalent to exeucting “git branch <dev-branch>” and “git checkout <dev-branch>” as you will create and move to the new development branch.

You created a new branch and moved to the new branch!

You have now moved to the new development branch as indicated at the bottom left corner.

Next, let’s create your Python script file in the new branch!

Click File, New From Template then Python File.

Type your python script under Untitled1.py window. Then click File and Save As.

Select your repositry name and name your python file, then click Save (See below).

Click Run. See the outcome of executing the python script.

See the change under my-python-repo repository under Source Control on the left side of your Cloud9 window.

“U” means untracked changes on the file. Placing a mouse cursor on “+” sign shows “Stage Changes”.

You have created a new Python script file in the local repository.

“Untracked File Change”: The Python file change is untracked.

When you place a mouse cursor in “U”, it will show other icons above.

Click “+” sign next to “U” to move the python file to the staging environment for tracking the changes on the Python file.

“Stage Changes”: The file change is now tracked in Staging Environment.

Type a commit message “Hello World!” in the Message blank (See above), then press “Control” and “Enter” key in turn to add the file into this local repository.

The Python file change is committed to the local Cloud9 repository.

Since all the files were committed to the local repository, there are “No changes detected”.

The new development branch contains the commit record tracking the changes on the Python file.

In a terminal mode, execute “git push” comamnd.

However, it will not still work out on the new branch because the information on the user making git commits is missing per error message. (No screenshot available)

Set up the user name and email of the person who makes git commits using the following two git config commands. Then execute git push command.

git config --global user.name "<username>"
git config --global user.email "<useremail>"
git push

The above git push command causes an error message.

Execute the recommended git push command above. Then provide the username and password(Personal access token) for your GitHub account.

git push --set-upstream origin <dev-branch>

git push command is sucessfully executed.

The python file in your Cloud9 local repository is successfully pushed up to the GitHub respository (See the above message).

The development branch (B) is pushed up to the remote repositry (C).

It generates the exact same development branch with the committed Python file in the remote GitHub repository (C).

After making Git push, you can see the changes on the icons at the bottom left corner of the Cloud9 window displaying 2 circling arrows next to your development branch name (See below).

Upon placing your cursor at the two circling arrow icon at the bottom left corner, it will display “Synchronize Changes” between the local Cloud9 repository and the remote GitHub repository.

Click the two circling arrow icon. Then it shows a warning message for pull and push commits to and from your development branch.
Click OK.

The next pop-up window asks about periodically running git fetch command. Select Ask Me Later.

Click two circling arrow icon again. Click “OK, Don’t’s Show Again.”

No further messge for push and pull commands will be displayed again.

Everytime when you make git push and pull in bash terminal, Git username and access token should be entered manually. It is not convenient (See below).

Let’s store the log-in credential for the GitHub remote repository.

Execute git config credential.helper store command. Then attempt to git push to provide the username and the Git personal access token. This process will capture the credential information.

Since the credential information is stored, there is no need to manually type the Git log-in credentials shown below.

Step 4. Check the remote GitHub repositry for a change.

Check the main branch on the remote repository below.

Check the uploaded dkim-03302023 branch below.

A python file exists in the uploaded branch, but not in the main branch on the remote repository. Therefore, we should reflect the commit of the file change in the main branch. Pushing the commit directly into the main branch is prohibited, so let’s follow each step:

[1] Open a pull request (PR) to ask for merging the uploaded branch into the main branch in the remote repository.

Click Compare and pull request button.

Add a message and click Create pull request.

[2] Approve the pull request.

Review the pull request below. Click View under No unresolved conversations.

It will show any changes between the uploaded branch and the main branch. The change of the content is acceptable per our review.

[3] Merge the uploaded branch to the main branch.

Check on Merging without waiting for requirements to be met.
Click Merge pull request. Then click Confirm merge on the next page.

You have successfully merged the branch into the main branch!

Click Delete branch.

See the next page showing the branch merging history below.

See the main branch containing the Python script.

In the remote GitHub repository, the uploaded development branch was successfully merged into the main branch!

The main branch (D) has the new Python file. The development branch (C) is eliminated.

[4] Delete the development branch from the local repository.

We should avoid creating time travel issues before and after the branch merging event by following the steps and the diagram below:

[4.1] In the local Cloud9 repository:
- Do not make a commit using the merged branch.
- Do not push the merged branch to the remote GitHub repository again.
- Delete the merged branch and the remote tracking branch.
[4.2] In the remote GitHub repository:
- Do not open a pull request (PR) for the merged branch again
- Delete the merged branch (We have already done so in [3]).

All the blue crosses indicate that we should stop keeping any further update on the main brach (D) in the remote repository using the merged development branch originating from the local Cloud9 branch.

[4.1] In the local Cloud 9 repository window,
- Click the merged branch dkim-03302023 icon at the bottom left corner, then click the main branch (commit 7dcdc342) on the left.
- At the bottom left corner, click the icon of two circling arrows to synchronize latest changes from the remote GitHub repository to the local Cloud9 repository with the following consequences:

The Python file in the main branch from the remote repository was automatically pulled down to the main branch in the local Cloud9 repository (See the Hello_world.py file).

Since the merged branch (C) was removed from the remote GitHub repository, the python file inside the branch (C) was also removed. The deleted status of the Python file was also reflected to the development branch in the local repository(B). It resulted in deleting the Python file present in the branch (B), accordingly. That is the reason why the following pop-up message asked whether we still wanted to keep the file open in the Cloud9 editor. Since the actual Python file has been already removed, I chose to close tab (See below).

The synchronization from the remote repository to the local repository did not automatically lead to eliminate the development branch (B) and the remote tracking branch present in the local Cloud9 repository (See the development branch, dkim-03302023, and remote tracking branch, origin/dkim-03302023, on the left side of the Cloud9 window.

We have to manually delete the development branch on the local Cloud9 repository.

We confirmed the deletion from the following cloud9 window.

We still found the remote tracking branch, origin/dkim-03302023 branch, in the local Cloud9 window (See above). Please do not click the remote tracking branch as it will automatically resurrect the deleted branch back to your local repository. Later, I learned that I could also delete these remote tracking branch using the following commands below. I really appreciate Joan Owusu for her help!

git branch -rd <remote-tracking-branch>

Finally, we successfully updated main branches on both remote repository and local repository (See the diagram).

Thank you for walking through the entire Cloud9 configuration process. Congratulations! You are now ready to use this configured local repository to update your remote GitHub repository! :-)

Additional information

To prepare block of codes to post in Medium blog, it is good idea to use GitHub Gist website. I really appreciate Zaire Ali for sharing this great tip!

GitHub Gist helps to present a bundle of codes in an organized manner.