Giving instructions is as old as time,  but with time society has adopted different mediums of communicating instruction to the intended audience. Some have proven more effective than others, one of the most effective mediums is Richar Mayer`s 12 Principles of Multimedia Learning- an interdisciplinary approach to designing instructions, it is often referred to as a cognitive theory of multimedia learning. models of instructional design Table of Contents: Richard Mayer’s 12 Principles of Multimedia Learning- an interdisciplinary approach to designing instructions. It is often referred to as a cognitive theory of multimedia learning. What is multimedia learning? How to improve retention in learning? How do we process information? What is Cognitive Load? The 12 Principles of Multimedia Learning Thank you Mr Mayer`s What is Multimedia Learning? Multimedia Learning refers to the use of pictures and words as the primary medium for learning. It is described as a type of computer-assisted training that employs two modalities at the same time. The Multimedia principles assert that deeper learning occurs from words and pictures than from just words, but this does not refer to adding random pictures to the learning experience. The addition of pictures to learning in this principle is guided by the three assumptions of cognitive science. The assumptions explore possible ways humans process information. Active processes assumption Here it is assumed that humans are not passive information absorbers, instead, they engage in active cognitive processes such as identifying, organizing, selecting, and integrating bits of the knowledge they garner in learning situations. This speaks to the fact that students are not empty vessels waiting to be filled but individuals with the capacity to synthesize images and texts to create meaning that is stored in long term memory. Dual-channel assumption: Richard Mayer surmises that “humans possess separate channels for processing visual and auditory information, namely the visual-pictorial channel(which processes images seen through the eyes) and the auditory-verbal channel(which processes spoken word). Limited-capacity assumption Mayer suggests that humans have a specific limit on the amount of information they can process at any given time. https://www.youtube.com/watch?v=d9WpfWriY7A Benefits of Applying the Multimedia Principles It takes into cognisance the limitation of working memory which enhances the nature and presentation of instruction to aid the learning experience. All types of cognitive overload are avoided Cognitive Load Theory Cognitive Load occurs when text and images are presented simultaneously, this occurs because the information presented exceeds the learner's cognitive processing capacity. Cognitive load theory indicates that the kind of information we encounter during learning influences the way the brain processes information. There are three types of cognitive load which determine brain processing namely;Extraneous Cognitive Load is wasted cognitive effort on material that does not support learning goals; Intrinsic Cognitive Load refers to the complexity of the information to be processed; and Germane Cognitive Load refers to the work involved in learning from the instruction. This can occur when you give a child in a lower grade work from a higher grade. Reducing Cognitive Load in Multimedia Learning Off-loading: Ensure there is a balance between visual and audio information.
Segmenting: Include breaks between learning segments to allow for assimilation of information.
Pre-training: Include relevant names and characteristics of topics and subjects.
Weeding: Remove excess and uninteresting material.
Signaling: Insert cues for how to process material to streamline the material that is processed.
Aligning: Place text near corresponding graphics to reduce the need for visual scanning.Eliminating Redundancy: Avoid presenting identical written and spoken words.
Synchronizing: Present audio and corresponding images concurrently.Individualizing : ensuring the learner has the skill to process mental representations. 12 Principles of Multimedia Learning The Coherence Principle “Humans learn best when extraneous, distracting material is not included.” Simplicity is crucial in designing a learning experience, therefore instructors must refrain from using complex or and complicated information. Also they must refrain from putting all applicable information on the subject matter. The goal is to have only information that will be assessed,if not the learner will be distracted.  In order to ensure this use simple visuals, avoid using background music and include only relevant images. The Signaling Principle “Humans learn best when they are shown exactly what to pay attention to on the screen.” Too much information on the screen will lead to distracted learning which isnt really learning.  To achieve this use fewer bits of information and add arrows for directions. The Redundancy Principle “Humans learn best with narration and graphics, as opposed to narration, graphics and text.”
If you have narration and graphics, adding text is redundant and can be overwhelming for the learner. In layman terms this principle means, if there is voiceover narration only using graphics on screen any other media added to the material would be redundant. The Spatial Contiguity Principle “Humans learn best when relevant text and visuals are physically close together”. The goal here is to ensure all words and images are aligned, this enables learners to focus, reduces the cognitive effort expanded on trying to align the elements on the screen. To achieve this, ensure text and related graphics are in close proximity, have learners read text before playing any animated graphic and add pointers on the screen. The Temporal Contiguity Principle “Humans learn best when corresponding words and visuals are presented together instead of inconsecutive order.” The mantra here is simultaneous not one after the other or Side by side not one after other.’ This lays emphasis on the learning material, reduces the learning time and improves the overall experience. You can achieve this by ensuring the audio and image occur at the same time. The Segmenting Principle “Humans learn best when information is presented in segments, rather than in one long continuous stream.” Segmenting learning sessions enables learners to feel in control of their learning experience and keep track of learning progress. Using “next buttons” in online learning materials can achieve this very easily. The Pre-training Principle “Humans learn more effectively if they already know some of the basics” Thus it is important for learners to already know some key terms, definitions and concepts before delving into the immersive learning experience.  This can be practised using an introductory guide or cheat sheet as the pre-classes guide. The Modality Principle “Humans learn best from visuals and spoken words than from visuals and printed words.” It is important to balance the ratio of texts and images to ensure the learner is not overwhelmed. To achieve this use use voiceovers in learning materials as opposed to on screen text. The Multimedia Principle “Humans learn best from words and pictures than words alone.” This principle works best when relevant, memorable and intriguing images are added to the learning experience. It requires a balance of images and words to create an immersive learning experience. The Personalization Principle “Humans learn best from a more informal, conversational voice than an overly formal voice.” This creates a comfortable atmosphere for learning which improves the learning experience. It is important to use simple language, use first-person and match the tone of the speaker to the learner demographic. The Voice Principle “Humans learn best from a human voice, not a computer voice.” With the rise of Siri and Alexa it is easy to delegate the voicing to a computer application however, the trick here is to use a human voice not the voice of a robot or a computer voice. The Image Principle “Humans do not necessarily learn better from a talking head video”, the logic applied here suggests that important information should be learnt using relevant visuals not a talking head. The trick here is to use relevant animations or images to reinforce the audio voiceover. https://www.youtube.com/shorts/X4ymLh0fPis Thank you Richard Mayers! The cognitive theory of multimedia learning assumes that the human mind is a dual-channel, limited-capacity active-processing system, and that presenters must design multimedia messages to account for all three types of cognitive load. Mayer takes a constructivist approach to learning, in which multimedia are seen as cognitive supports for knowledge building rather than information delivery methods. Essentially Mayers has taken into consideration the limits to human assimilation and provided parameters to ensure engaging and effective learning. Thank you Richard Mayers for providing these principles which are reshaping the creation of learning materials therefore shaping learning experiences. More in Instructional Design Mayers Principle of Multimedia Learning Arcs Model: Motivation as a Tool in Education Activity-Centered Instructional Design Model: An Analysis of Action Mapping

Richard Mayer's Cognitive Theory of Multimedia Explained: An Instructional Designer's Perspective

A Guide to 99% Fault Tolerant Consensus and What it Entails

A Guide to 99% Fault Tolerant Consensus

How to Use NextJS, TypeScript, Tailwind, and OneEntry CMS to Build an eCommerce Store 🛒👨‍💻

কিভাবে NextJS, TypeScript, Tailwind, এবং OneEntry CMS একটি ইকমার্স স্টোর তৈরি করতে ব্যবহার করবেন 🛒👨‍💻

So verwenden Sie NextJS, TypeScript, Tailwind und OneEntry CMS zum Aufbau eines E-Commerce-Shops 🛒👨‍💻

Cómo utilizar NextJS, TypeScript, Tailwind y OneEntry CMS para crear una tienda de comercio electrónico 🛒👨‍💻

Comment utiliser NextJS, TypeScript, Tailwind et OneEntry CMS pour créer une boutique de commerce électronique 🛒👨‍💻

ईकॉमर्स स्टोर बनाने के लिए नेक्स्टजेएस, टाइपस्क्रिप्ट, टेलविंड और वनएंट्री सीएमएस का उपयोग कैसे करें 🛒👨‍💻

NextJS、TypeScript、Tailwind、OneEntry CMS を使用して e コマース ストアを構築する方法 🛒👨‍💻

NextJS, TypeScript, Tailwind 및 OneEntry CMS를 사용하여 전자상거래 상점을 구축하는 방법 🛒👨‍💻

Como usar NextJS, TypeScript, Tailwind e OneEntry CMS para construir uma loja de comércio eletrônico 🛒👨‍💻

Как использовать CMS NextJS, TypeScript, Tailwind и OneEntry для создания магазина электронной коммерции 🛒👨‍💻

Bir e-Ticaret Mağazası Oluşturmak için NextJS, TypeScript, Tailwind ve OneEntry CMS Nasıl Kullanılır 🛒👨‍💻

Cách sử dụng NextJS, TypeScript, Tailwind và OneEntry CMS để xây dựng cửa hàng thương mại điện tử 🛒👨‍💻

如何使用 NextJS、TypeScript、Tailwind 和 OneEntry CMS 构建电子商务商店 🛒👨‍💻

Over the past few weeks, I have been exploring the world of entrepreneurship, attending various events where accelerators gather, joining breakfasts for entrepreneurial-minded individuals, and participating in debates on the subject. Throughout this journey, I have been focusing on funding opportunities, education, and mindset shifts that ultimately lead to the creation of successful businesses. An opinion piece that caught my attention was one by Adam Molai entitled " ," along with the paper " ," both of which form the basis of my thoughts today. Africa lacks the right kind of entrepreneurs Jobs, Economic Growth and Capacity Development for Youth in Africa Indulge With the world at 8 billion persons as of , Africa remains one of the poorest continents on the globe, despite the fact that it will account for 2 out of 5 working-age individuals by the end of the 21st century. The peculiar part of this statement is the quality and purposes with which we build our ventures within the African economic zones. 15th November 2022 The crux? Was this business built out of a pure innovative spirit - to create what once was not - or was it a means to an end? Returning to the population question, with a 245.0% increase in population within the working age group, we expect a rise in the number of graduates and professionals alike. All this while, the market is not primed to absorb this number of individuals. If anything, the that have happened over the last couple of months have been a testament to what happens when projects fail and companies are bloated. tech lay-offs Was this business built out of a pure innovative spirit - to create what once was not - or was it a means to an end? This raises the question, what does this mean for education? Having been brought up in an African household and in relation to how we raise this generation of dreamers and builders alike, provided we exist in the space where entrepreneurship is treated as a ‘side-hustle’ for those incapable of being absorbed into the job market, we cease to create foundations upon which the future can stand. The next Bill Gates will not build an operating system. The next Larry Page or Sergey Brin won’t make a search engine. And the next Mark Zuckerberg won’t create a social network. If you are copying these guys, you aren’t learning from them. - Peter Thiel (Zero To One) It is high time we create sustainable solutions that navigate from bringing in the everyday meal to those that impart beyond sustenance. To leave you something to nibble and ponder, here is an article from TechCabal about . tech talent navigating its way back to Africa Thought: Perhaps the danger of Artificial Intelligence is not in it taking away employment ( unless you champion ) but in that with the increased use of the same technology, AI relearns from itself and other old content rather than what is made a-new. The limit remains; Artificial Intelligence will only learn from what already exists. bullshit jobs Also published . here

Necessity versus Opportunity — Africa’s Relationship With Entrepreneurship

With the recent sell-off in global markets, we wanted to take the time to review the performance of our investment strategies in cryptocurrencies and evaluate the risk in them. The graph shows the performance of the cryptocurrency market since our first day of trading on 12/15/2017 until today (updated daily) as well as the performance of the different investment styles like momentum and small cap. We also show the performance of Bitcoin for comparison. Only momentum investing has made money since inception, while all other investment styles have lost money. here The idea behind investment styles is backed by solid academic research, aiming at above-average risk-adjusted returns and explaining market returns (see for an introduction). here What did we learn from last two years of trading? All returns above are calculated from a long only portfolio that is selected daily based on each investment style as explained . We think there are the following important learnings: here 1. Momentum has largely outperformed all other investment styles, because it participates in market rallies, but goes into cash during bear markets 2. Momentum is biased towards the small cap investment style due to the risk weighting of the index (it is more equal weighted than market cap weighted) as explained here 3. Small cap (altcoin overweight) has outperformed the market initially and then underperformed Why was momentum trading so successful? Since momentum has had such a phenomenal performance compared to the other investment styles, we want to dive in a bit deeper into the mechanics. Most importantly, momentum is considered to replicate a call option (for example see ). The idea behind a call option is to let an investor only participate in an up-market and not in the down-market. Ideally the call option would only have upside, but no downside. Unfortunately, the call-option has to be bought for a fixed price, which is called the option premium. Hurst et al. 2013 At the moment, the call option for Bitcoin costs around 20% of the notional investment per quarter. That means, the investor will lose 80% of his investment over one year unless Bitcoin rallies and the call-option runs into the money. Momentum strategies became famous, because they were able to replicate call options for a lot less (see ). We estimate that the cost to replicate the call option with a momentum strategy is about 10% per year, so in fact eight times cheaper than an outright call option (see below). Hurst et al. 2013 We have discussed this for cryptocurrencies in 2017 , but wanted to review the results during our live trading. The headline figure shows the performance of the momentum investment style versus market returns over rolling 90 days. The figure also shows a fitted call option. As discussed above, trading long only momentum is replicating a call option. The figure shows that the return profile of momentum trading is very similar to a call option. here However, the investor in this strategy is not fully hedged when the market sells off. Especially if the market sells off up to 25%, the momentum strategy is still very much affected and only slightly reduces the risk to about 20%. However, the momentum strategy has worked well in larger sell-offs and reduced risk to about 10%. We calculated the average performance of the momentum strategy over 90 days, when the market performance was negative over the same period, to 2.66% and hence 10.66% over 1 year. If the replication of a call option works well with the momentum investment style what about put options and even selling options? Well, the same principles apply. Building a put option with momentum is essentially trading the short signals and has the pay-off profile as shown below. Of course, the put option has a higher premium as financial markets are risk averse and are generally protecting against the downside (see for an introduction). If you now trade the momentum investment style long and short, then of course, we can replicate a so-called long straddle. The straddle is a simple combination of the call and put option and rewards the investor if the market is either rallying or selling off. volatility smile However, the investor has to pay both the call and put option premium, so the straddle is even more expensive. At Protos we only trade momentum long-only exactly because the put option replication is even more expensive and because we are optimistic about the general market. What about selling options? The pay-off profile for a short straddle is just the opposite of the long straddle, which is selling both a put and a call option. In this case, the investor is collecting the option premium. Therefore if the market moves sideways, the investor is generating a constant yield. However, if the market either goes up or down substantially, the investor is facing unlimited losses. That is why we think a lot of funds and investors that implement this strategy, have gone out of business. If momentum investing is replicating a long straddle, then the opposite of momentum investing should be a short straddle. What is the opposite of momentum investing? So consider the following market scenario: If the market has already dropped substantially, the momentum investor would go either into cash (long-only momentum investing replicating a call option) or go outright short in this market (long and short momentum investing replicating a straddle). The opposite strategy would of course be to buy this market and feel that the market is cheap and betting on a recovery. Of course if the market continues to fall, then this investor would face potentially unlimited losses. This strategy is called in general a mean-reversion strategy and is applied by market makers. As market makers are always quoting both sides, they are inherently facing the risk that the market continues in one direction and that they cannot close their positions. Another name of this strategy is buying-the-dip and it always has the risk of unlimited losses. Which strategy is better — momentum or buy-the-dip? Well that of course depends on the market and the risk appetite of the investor. The advantage of momentum investing is that the downside risk is pretty limited, but on the other hand loses small amounts of money over time if the market moves sideways. The advantage of buy-the-dip is that this strategy generates usually a yield and increases the holdings slowly over time. On the other hand, this strategy is facing an unlimited loss, especially if the dip is bought multiple times with leverage. Since this strategy is applied by market makers, they usually have good performance for a period of time, but then get wiped out in an unexpected market crash like this one during March 2020 in both equity markets and crypto markets. In fact, we believe this is the reason why there are very large famous hedge funds and not many famous market makers — ultimately they just get wiped out once in a while. Or as the saying goes: “The trend is your friend”. About us Protos Cryptocurrency Asset Management invests and trades established tokens like bitcoin using advanced quantitative strategies. It’s founders have 13 years combined experience investing in crypto, have managed funds/proprietary investments of over $1B, have founded and sold 3 tech startups for proceeds of 400M and 1 investment bank at a valuation of $250 million +. ( : ) Disclaimer The author is a co-Founder and CIO at ProtosFund

Cryptocurrency Investment Strategies: Momentum Trading versus Call Options [Reviewed]

Why I’m Excited for JavaScript Class Private Fields: A Case Study

GitHub actions and workflows are great. We use them to deploy a web app to different cluster environments and I want to show you how we did it. Hopefully, this helps to simplify your deployment process as well. I’ve also written a companion article that describes our . GitHub workflows for continuous integration Here, we’ll focus on our continuous deployment process: Workflow Overview Our continuous deployment workflow has four jobs. It includes the same jobs that we had in our continuous integration workflow, as well as two extra jobs: ( ) Validate that the release has been tagged correctly. CD only ( ) Lint the code with Flake8 and test the application with Pytest. CI/CD ( ) Build a Docker Image and publish it to Google’s container registry. CI/CD ( ) Deploy the container to a Kubernetes cluster in Google Cloud. CD only Release Process Overview To understand our deployment workflow, you need to know a bit about our release process. As mentioned in the , we set up these workflows while building a web app for a major property tech startup. preceding article The web app consists of four sub-applications. Each application is maintained in a separate repo and runs in its own Docker container. For each repo, the workflow automation looks at certain attributes to determine which cluster to deploy to. Release Attributes When creating a release in GitHub, we use the prerelease flag to indicate that the release is not ready for production. In this case, the container is either deployed to a development or staging cluster depending on what branch was used to create the release. When we’re in the process of developing, we push everything to a branch and create a release from that branch. We set the prerelease flag and give it a descriptive tag with the prefix “ ” (release candidate). Development: rc- When we’re reading to push to staging for proper QA, we merge to master and create another release. We select the master branch but keep the prerelease flag. We add a tag that indicates the intended version, but we keep the prefix “rc-”. Staging: When we deploy to production we add a tag with the prefix “r-” and the “pre-release” flag is no longer selected. Production: The “ ” and “ ” tag prefixes enable us to easily distinguish between “real” releases and release candidates when reviewing the release history. As you’ll soon see, we automatically validate tag prefixes when deploying to a production cluster. r- rc- Create a workflow file Now that you understand our release process, the deployment logic in the workflow file will make a lot more sense. So let’s go through what we did to create it. By the way, I’m assuming you’ve created a workflow file before. If you haven’t, check out my first article on creating a workflow file for CI. I’ll be using the workflow file for our backend app as an example. Define the triggering event We wanted our deployment workflow to kick in whenever someone created a release in GitHub so we updated our workflow file as follows. name: CD on: release: types: [created] For more information on the trigger syntax, see GitHub’s . reference doc on events Define Jobs As mentioned in my introduction, we wanted to validate the GitHub tags and test the app, take a snapshot of it, and push it as a Docker image in our container registry (just in case we needed to roll back to an earlier iteration of the app). Finally, we wanted to deploy the image to a Kubernetes cluster. For this purpose, we defined these four jobs: : Validate tags. Job 1 : Run the tests. Job 2 : Build and publish the Docker image. Job 3 : Deploy the application to a cluster Job 4 If any one of these jobs fails, the whole workflow is terminated. I won’t go too much into job 2 and job 3 because they also exist in our CI workflow which I’ve covered in a companion article. Job 1 is interesting because we’re considering an action that we’ve created ourselves. Also, we store the action in a private repository which poses its own challenges as you’ll soon see. So let’s get into it: Job #1 (CD only): Validate release tags We wanted to easily distinguish different release types on our releases page — so we defined the simple tagging rules that I described previously. But rules are no good unless you can enforce them. Creating a custom action To check that people are tagging releases correctly, we created a custom action. GitHub actions are essentially small predefined scripts that execute one specific task. There are plenty of user-contributed actions on the Github marketplace, but in this case, we needed to create our own. GitHub supports two types of action: an action that runs as a JavaScript, or one that . runs in a Docker container We set up one that runs in a Docker container since that’s what we’re more familiar with. Our action lives in its own private repo with the following file structure. The most important files are the action metadata (“ ”) and the shell script (“ ”). action.yaml entrypoint.sh The actions metadata The file defines the metadata for the action, according to the actions.yaml metadata syntax . name: 'Validate tags' author: 'Hugobert Humperdinck' description: 'Validate release/pre-release tags' inputs: prerelease: description: 'Tag is prerelease' required: true runs: using: 'docker' image: 'Dockerfile' args: - ${{ inputs.prerelease }} It also defines the arguments that the action takes. In our action, we depend on the value of the prerelease flag for our validation logic, so we define it as an input for the action. The shell script The is the shell script to run in the Docker container. It includes all of our validation logic. entrypoint.sh -e -o pipefail BRANCH=$(git branch -r --contains | grep )
RELEASE_VERSION=$( | sed -e | sed -e )

MASTER_BRANCH_NAME= RELEASE_PREFIX= [[ != ]] && [[ == * * ]] && [[ == * ]]; 0 [[ == ]]; 0 1 #!/bin/bash set set echo "Start validation " $1 ${GITHUB_SHA} "" echo ${GITHUB_REF} "s/refs\/tags\///g" "s/\//-/g" 'origin/master' 'r-' if " " ${INPUT_PRERELEASE} true " " $BRANCH " " $MASTER_BRANCH_NAME " " $RELEASE_VERSION " " $RELEASE_PREFIX then echo "Release tag validation succeeded!" exit elif " " ${INPUT_PRERELEASE} true then echo "Pre-Release tag validation succeeded!" exit else echo "Tag validation failed!" exit fi Here’s what the script does. Set environment variables We’re using the built-in GitHub environment variables and to determine the following variables: GITHUB_REF GITHUB_SHA : Our validation logic depends on the branch name so we search through the branches for the commit that triggered the workflow and derive the associated branch. BRANCH : We search the full Git ref string to get just the tag at the end of the path. RELEASE_VERSION The variables and the are just hardcoded strings. MASTER_BRANCH_NAME RELEASE_PREFIX is the value of the prerelease flag and it comes from the input defined for the action (in ). When we call the action we pass the prerelease flag as an argument. INPUT_PRERELEASE action.yaml Validate Release Tag We want the tags to be formatted a certain way but we only care about tags for production releases. First, we make sure it’s a production release but specifying our two release criteria: the prerelease flag is not set and it’s on the master branch. The third criterion is that the has to start with “r-”. If it doesn’t have the right prefix, we fail the job, and consequently the entire deployment workflow. RELEASE_VERSION If the prerelease flag is set, we know it’s not a production release, then we just say that the tag is fine whatever it is. This logic could obviously be improved. We could check the prerelease flag in job definition, but my main goal is to show you how a basic action is structured. Calling the action from our job Normally, it’s easy to call an action from a workflow file — but that’s assuming the action is in a public repo. Our customer didn’t want to open up their source files for the world to see, so we needed to store our action in a private repository. Initially, this was a problem. It was so we couldn’t use an action stored there. I’m telling you this because we’re still in the process of updating our workflow since GitHub recently fixed this problem. difficult to check out a private repository Originally, checking out other repos was simple. When you wanted to clone your working branch to the virtual machine, you called the public action “actions/checkout” without any arguments. You could also pass it extra arguments to check out other public repositories. But version 1 of the action did not work so well with private repositories. It could check out the repository, but did not pass the path to the next workflow step. If you checked out a repo to the folder “my-magic-actions”, the workflow could not see it. checkout Luckily, version 2 of the checkout action fixes this issue and it supports SSH for accessing private repositories. Now, to use a private action, we can update our workflow file to check out our private actions repo like this: jobs: validate-release-name: name: Validate release name runs-on: 'ubuntu-latest' steps: - name: Checkout working branch uses: actions/checkout@v2 - name: Checkout private actions repo uses: actions/checkout@v2 with: repository: acme/private-actions token: ${{ secrets.GitHub_PAT }} # `GitHub_PAT` is a secret that contains your PAT path: private-actions In the job steps, we first call the checkout action without arguments to get the working branch for our application. Then, we call the “checkout” action to check out another private repo — the one that contains our action. again This time, we provide some extra parameters such as the repo path, the local path and the GitHub personal access token (PAT) for the actions repository. We can’t use because it is scoped to our backend repository, so we have to specify a separate PAT that has access to the repo for our private actions (the ‘secrets’ variables are defined in the .) ${{ github.token }} repository settings For more information on how the Checkout action works, so the . checkout README After all that, we can finally call our private action with the prerelease flag as an argument. - name: Validate release tag uses: private-actions/validate-tag-action with: prerelease: 'github.event.release.prerelease' We get the prerelease flag by using the GitHub . context syntax Job #2 (CD/CD): Run the tests. These are the same tests that we use in our continuous integration workflow which I have already covered in . a companion article Job #3 (CD/CD): Build the Docker image and publish it to registry Again, I already covered this job in my , but there is one small difference this time around. We add the parameter which changes how we tag the Docker image. companion article tag_names - name: Publish Docker Image uses: elgohr/Publish-Docker-Github-Action@2.14 env: SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }} with: name: ${{ env.DOCKER_IMAGE }} username: ${{ steps.gcloud.outputs.username }} password: ${{ steps.gcloud.outputs.password }} registry: ${{ env.DOCKER_REGISTRY }} tag_names: true buildargs: SSH_PRIVATE_KEY Instead of sticking with the default behaviour, which is to tag the image with the originating branch, we pass the value of the as our Docker tag. So in the Docker registry, released images look something like this: GitHub release tag : : Name 8cd6851d850b Tag r-3 Again, this enables us to visually distinguish released Docker images from ones that were pushed as part of the continuous integration workflow. As a reminder, pre-release images are tagged with the branch name like this: : : Name 8cd6851d850b Tag XYZ-123_add_special_field_todo_magic Job #4: Deploy to Google Cloud Assuming the previous job succeeds, we’re ready to push the Docker image to a Kubernetes cluster in our Google Cloud instance. First, we need to set a few environment variables: Set up the environment We updated our workflow file as follows: deployment: name: Deploy backend to cluster runs-on: 'ubuntu-latest' needs: [docker-image] steps: - name: Checkout working branch uses: actions/checkout@v1 - name: Set Release version run: |
        echo ::set-env name=RELEASE_VERSION::$(echo ${GITHUB_REF} | 
                            sed -e "s/refs\/tags\///g" | sed -e "s/\//-/g") - name: Cluster env for production if: "!github.event.release.prerelease" run: |
        echo ::set-env name=CLUSTER_ENV::prod - name: Cluster env for staging/dev if: "github.event.release.prerelease" run: |
        BRANCH=$(git branch -r --contains ${GITHUB_SHA} | grep "")
        MASTER_BRANCH_NAME='origin/master'
        if [[ "$BRANCH" == *"$MASTER_BRANCH_NAME"* ]]; then
          echo ::set-env name=CLUSTER_ENV::stag
        else
          echo ::set-env name=CLUSTER_ENV::dev
        fi - name: Set Cluster credentials run: |
        echo ::set-env name=CLUSTER_NAME::acme-gke-$ echo ::set-env name=CLUSTER_ZONE::europe-west3-a
        echo ::set-env name=PROJECT_NAME::acme-555555 {{ env.CLUSTER_ENV }} We check out the working branch again (you have to do this for each job), then set by extracting the tag name from the end of the . RELEASE_VERSION GITHUB_REF Then we need to set all the variables that we’ll use for the “gcloud” command in a subsequent step: : We have some simple logic for defining how to do it: CLUSTER_ENV If the prerelease flag is not set, it’s a proper release and we set it to “prod”. If the prerelease flag is set, we check the originating branch. If the branch is master, we set it to “stag” (staging), and if not we set it to “dev”. : We use the variable to set the suffix for the full name. So it’s either “ ”, “ ”, or “ ”. CLUSTER_NAME CLUSTER_ENV acme-gke-prod acme-gke-stag acme-gke-dev The zone and project name are hardcoded. Install the necessary tools Next, we need to install the Kubernetes command-line tool and Helm, which makes it easier to install Kubernetes applications. - name: Install kubectl run: |
        sudo apt-get install kubectl - name: Install helm run: |
        curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
        chmod 700 get_helm.sh
        ./get_helm.sh Note that these tools seem to be . But they weren’t when we set up our workflow file, so I’ll stick to describing what we did. preinstalled in the standard GitHub virtual machines now Deploy the image to a cluster Finally, we use all the variables that we defined previously to run the gcloud CLI. - name: Deploy Release on cluster env: GCLOUD_KEY: ${{ secrets.GCLOUD_KEY }} run: |
        echo "$GCLOUD_KEY" | base64 --decode > ${HOME}/gcloud.json
        gcloud auth activate-service-account --key-file=${HOME}/gcloud.json
        gcloud auth configure-docker
        gcloud container clusters get-credentials \
        $ --zone 
        $ --project $ # install/upgrade helm chart
        helm upgrade --install backend ./deploy/helm/backend \
                  --values ./deploy/helm/backend/env.values.$ .yaml \
                  --set env_values.image_version=$ {{ env.CLUSTER_NAME }} {{ env.CLUSTER_ZONE }} {{ env.PROJECT_NAME }} {{ env.CLUSTER_ENV }} {{ env.RELEASE_VERSION } First, we get our Google Cloud key from our repository secrets then we give it to the gcloud CLI as well as our cluster and project details. Then, we use a to instgkecoall our back end application on the Kubernetes cluster. The Helm chart for the back end is stored in the backend repo because we prefer to maintain charts as part of the application (more on that in another article). Helm chart When installing, we pass Helm the following arguments to override the default settings in the chart: defines the yaml file that contains the environment variables. For a production release, it’s “env.values.prod.yaml”. — values overrides a specific variable in the “env.values” yaml file, namely “image_version”. In the yaml file, it’s set to “latest” but we want it to use our release version such as “r-3”. — set And that’s the end of the workflow. Once it’s triggered, it’s easy to monitor the progress and make sure that everything is deployed correctly. For example, here’s a screenshot of the output for one of our other public projects: Summary As I mentioned in the of this two-part series, it was very easy to set these workflows up. The limitation with actions in private repos was a minor irritation, but GitHub is continually improving their built-in actions as this was soon addressed. Plus there is a growing ecosystem of user-contributed actions for every kind of task. Unless a customer wants us to use something else besides GitHub, we’ll be sticking with GitHub CI/CD workflows for future projects. first part A Disclosure Note On The Author and Project A Merlin blogs about developer innovation and new technologies at Project A — a venture capital investor focusing on early-stage startups. provides operational support to its portfolio companies, including developer expertise. As part of the IT team, he covers the highlights of Project A’s work helping startups to evolve into thriving success stories. Project A

GitHub Actions: How To Deploy To Google Kubernetes Engine

Stories, News & Mentions about X4Y

X4y’s Stories on HackerNoon