WEEK 3: ENTRY 2

 Today at my internship, it must be said that things are now getting into the nitty gritty. Over the past couple of weeks, I have been setting up environments and learning the Go programming language, but today was a little different. Unlike those weeks, I had the opportunity to get started on my project today. My manager finally introduced me to the milestones or project timeline if you would like to put it that way. I was not expecting him to divide my project into different sections like the way he did. My presumption was that I would be given the main components and be told to develop the project from scratch up to the final product. However, it appeared that just like how the Student Software Developer team at Berea College uses the Agile methodology, my project will be using a similar approach. Instead of Trello, my team uses a dashboard called Jira to assign issues to me. It is a very user-friendly interface, where I can mark my current issue as in-progress, or under review, or done. These features are very vital because I can track my progress, while organizing my tasks in a more diligent way. 


My issue today was called “systemlog-119-kubernetes.” What does this mean? This is the generic way that I will be naming the issues throughout my project. The most important part is the last part, kubernetes because it describes the issue/stage that I am currently working on in my project. Thus, it can be inferred that today I was working on setting up my kubernetes on the cluster for the Continuous Integration/ Continuous Deployment, CI/CD. As part of the surprises today, I was not expecting this issue to be the first part of my project because I thought that deployment was going to be the last part of my project. Well, it is the total opposite. It turns out that the setup is needed because I will be continuously building and deploying simultaneously to allow organizing and shipping my application in a more fast and efficient way. This is a very great insight because I could never have imagined that it will be more efficient and faster this way. 

So too, setting kubernetes to connect with my Gitlab was not as easy and simple as it looks on the documentation. I struggled with the Gitlab pipeline building because whenever I committed and pushed my code, not all cases were passing. I consulted my manager, who suggested that I needed certain permissions. But even after the permissions were granted, a couple more were failing. Thus, I had to go through the documentation one more time to make sure that I was actually doing the right thing.  My build-up was still failing still, so I will have to wait until tomorrow and consult the Kubernetes specialist because time could not permit that today. I must say that I was freaked out but my manager said I should not worry because it does pose a problem when setting this all up at once. Overall, I was happy that I wrote code that was about to be deployed, but at the same time disappointed that it could not get built. 


Comments

Popular posts from this blog

WEEK 4: ENTRY 3

WEEK 6: ENTRY 3

WEEK 7: ENTRY 1