{"id":7083,"date":"2023-04-24T12:25:56","date_gmt":"2023-04-24T10:25:56","guid":{"rendered":"http:\/\/blog.bart.sk\/en\/?p=7083"},"modified":"2024-01-25T13:59:39","modified_gmt":"2024-01-25T12:59:39","slug":"how-do-we-do-cicd","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/how-do-we-do-cicd\/","title":{"rendered":"How do we do CI\/CD?"},"content":{"rendered":"

If you’ve read the <\/b>article about the benefits of CI\/CD<\/b><\/a>, you may have been motivated to deploy these practices on your project too, and now you’re wondering how to get started. In short, to put CI\/CD theory into practice, you need to design a system to deploy new code into production. This system is called a pipeline and consists of jobs that are performed automatically. How do we set it up at Crossuite?<\/b><\/p>\n

Currently, we use two tools for CI\/CD, namely GitLab and Jenkins. We’re using GitLab more intensively and we’d like to eliminate Jenkins altogether, because it’s difficult to integrate with Gitlab and it provides insufficient feedback for developers.\u00a0<\/span><\/p>\n

My colleague \u0160afo wrote an <\/span>article<\/span><\/a> about how to set up automated deployments via GitLab, so if you use it, you’ll find a great tutorial there.<\/span><\/p>\n

The process itself is divided into two<\/b> pipelines<\/b>, each with several jobs that can end in failed\/successful states.<\/span><\/p>\n

The merging pipeline includes:<\/b><\/p>\n

    \n
  1. Code Formatting<\/b> \u2013 Each new code is formatted according to the project’s set standards. As a result, fewer unnecessary conflicts arise in the merge and the code reads better overall.\u00a0<\/span><\/li>\n
  2. Linting<\/b> \u2013 ESLint performs static code analysis, again according to the best practices and standards set for the project. The program runs through the entire code and notifies you of unused variables, non-executed codes, and so on. Any discrepancies are then divided into warnings and errors. Notifications are just friendly recommendations for editing, but errors simply don’t pass through the job and the programmer has to fix them.<\/span><\/li>\n
  3. Build<\/b> \u2013 This build is for testing and includes:<\/span>\n
      \n
    1. Minification\/Uglification of code<\/b> \u2013 To simply make the project smaller.<\/span><\/li>\n
    2. Transpilation of typescript into javascript<\/b> \u2013 So that each browser can deal with the functionality.<\/span><\/li>\n
    3. Splitting into chunks<\/b> \u2013 So that we can dynamically load javascript while the application is running.<\/span><\/li>\n<\/ol>\n<\/li>\n
    4. Testing<\/b> \u2013 At this point, we launch a series of simple automated tests<\/span>\n
        \n
      1. Unit tests<\/b> \u2013 They only test individual functions or small pieces of code without external dependencies.<\/span><\/li>\n
      2. Integration tests<\/b> \u2013 They check how components within one system (API, FE, microservice) communicate with each other.<\/span><\/li>\n
      3. Bonus: End-to-end tests<\/b> \u2013 In the case of important merges, we also run more demanding end-to-end tests that will automatically click through to the project.<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

        If the entire pipeline lights up green, and we therefore have success, the code will successfully merge and pipeline 2: deployment, is triggered.<\/b> It contains everything that the migration pipeline does, plus some little things. <\/span>If this pipeline is also successful, the update will be deployed “live”.<\/b><\/p>\n

        But what if we don’t want to show users what we’re deploying yet? Hide it under the feature flags! We’ll write about them next time. ?<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"If you’ve read the article about the benefits of CI\/CD, you may have been motivated to deploy these…","protected":false},"author":27,"featured_media":7311,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","csco_display_header_overlay":false,"csco_singular_sidebar":"","csco_page_header_type":""},"categories":[335,199],"tags":[402,312,408,409,219],"_links":{"self":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7083"}],"collection":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/comments?post=7083"}],"version-history":[{"count":1,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7083\/revisions"}],"predecessor-version":[{"id":7084,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7083\/revisions\/7084"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media\/7311"}],"wp:attachment":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media?parent=7083"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/categories?post=7083"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/tags?post=7083"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}