{"id":16,"date":"2022-04-15T03:49:38","date_gmt":"2022-04-15T03:49:38","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/duclosa\/?p=16"},"modified":"2022-04-15T03:49:38","modified_gmt":"2022-04-15T03:49:38","slug":"everything-everywhere-all-at-once-starting-our-project","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/duclosa\/2022\/04\/15\/everything-everywhere-all-at-once-starting-our-project\/","title":{"rendered":"Everything Everywhere All At Once, Starting our Project"},"content":{"rendered":"\n

Well, it\u2019s time! With our rough project plan in place, and a general idea of what we are all supposed to be doing and when, it\u2019s time to dive head-first into creating our project! My task for this week was to develop and implement a useful CICD workflow and start on the webpage for our admins that allows them to create, read, update, and delete pets from their repertoire. There was quite a lot of unknown territory getting started with all this, and I felt a bit overwhelmed at certain points (cough-cough spending a whole day banging my head into the wall fixing one dependency issue), but I was able to hit my goals so far. Let\u2019s get into it.<\/p>\n\n\n\n

I’ll be the first to admit that I\u2019m no wizard with VCS systems. I\u2019ve kind of abused them as basically remote drop-boxes to store my code somewhere else while in college, which while decentralized storage is an important part of any VCS system, it is not its sole purpose. Furthermore, when multiple people get involved, it introduces a lot more complexity. I learned a lot more about what advanced features were available to me with the popular VCS system GitHub while taking my software engineering II class, and I decided to take what I learned about creating a continuous integration and deployment system in GitHub and use that as a jumping off point for our project.<\/p>\n\n\n\n

So, what the heck is continuous integration and continuous deployment (CICD)? Well, continuous integration is basically an automated workflow that will take new changes to a project and automatically, build it, lint it, test it against a specified test suite, and merge it with a specified branch. Note that the merging part isn\u2019t usually automatic and will require some kind of code review and sign off before anything in merged to the main branch in the repo. It\u2019s not uncommon to do a this via a pull request on github. As for continuous deployment, this occurs after CI and is once new change(s) are actually merged to the project being developed, the project is then automatically deployed to the appropriate localization. E.G. a web app is deployed to a server.<\/p>\n\n\n\n

So what approach did I take to apply this to our project? I wanted to try and minimize the risk of breaking our project as much as possible, so I opted to have two \u201cmain\u201d branches in our repo, develop and production (main). The idea here being that we will work off the develop branch in our own local branches to add new features, then there will be a CI workflow triggered when we push our changes out to develop that will build, lint, and test our code. Then our changes will automatically be deployed to a development heroku server so that we can non-functionally test and further integrate\/review our changes. Team members will not be able to merge to Develop without sign off from at least one other person, this mechanism will act as our code review and will be done via a pull request.<\/p>\n\n\n\n

There will also be a production branch. The idea here is that once we have implemented and fleshed out a set of new features on the develop branch, and we are happy with the current state, we will merge the current state of develop into main and this will be considered what\u2019s currently \u201cdone\u201d for our project. Having this separate branch will allow us to have a rollback point if we irreversibly mess up our develop branch, and also act a mile stoning system to gauge our progress. There is a another CICD workflow for the production branch that pretty much does the same thing as the pipeline for develop, the only difference here is that the production workflow deploys to a separate heroku server that is solely for the production version of our app. No merges to this branch will be able to happen without explicit approve from all the team members.<\/p>\n\n\n\n

Here is a general idea of how this workflow works at a high level.<\/p>\n\n\n\n

\"\"
src:<\/strong> https:\/\/blog.logrocket.com\/ci-cd-pipelines-react-github-actions-heroku\/<\/figcaption><\/figure>\n\n\n\n

Here are what the devlop CI workflow .yaml file looks like, production is remarkably similar.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

As far as adding code to the front-end admin page that I was tasked with working on, this was an ordeal. I was exposed to basic design paradigms of React and built a simple SPA app using the MERN stack in my web development class, but I still largely am inexperienced with putting together anything functional with React. I was able to start adding components to the page but was not able to get that far. I\u2019ll have more updates on this in my next post. Here’s where I left off as of writing.<\/p>\n\n\n\n

\"\"<\/p>\n","protected":false},"excerpt":{"rendered":"

Well, it\u2019s time! With our rough project plan in place, and a general idea of what we are all supposed to be doing and when, it\u2019s time to dive head-first into creating our project! My task for this week was to develop and implement a useful CICD workflow and start on the webpage for our […]<\/p>\n","protected":false},"author":12294,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-16","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/posts\/16","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/users\/12294"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/comments?post=16"}],"version-history":[{"count":1,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/posts\/16\/revisions"}],"predecessor-version":[{"id":19,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/posts\/16\/revisions\/19"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/media?parent=16"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/categories?post=16"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/duclosa\/wp-json\/wp\/v2\/tags?post=16"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}