{"id":305,"date":"2016-02-17T11:08:44","date_gmt":"2016-02-17T10:08:44","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=305"},"modified":"2023-06-09T14:14:51","modified_gmt":"2023-06-09T12:14:51","slug":"jenkbird-the-art-of-deployment-tutorial-part-2","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/02\/17\/jenkbird-the-art-of-deployment-tutorial-part-2\/","title":{"rendered":"Jenkbird – The art of deployment – Part 2"},"content":{"rendered":"
\n
\n
  One stage. Two stages. THREE STAGES FOR DEPLOYMENT!<\/div>\n
\u2014 Count von Count on his deployment pipeline
\n<\/em><\/div>\n<\/div>\n<\/blockquote>\n

Hi, it’s us agai\"count_dracula\"<\/a>n, the guys with the strange idea of using Sesame Street characters in a blog series about CI. Since we didn’t really cover the reasons, why you should use CD \/ CI<\/strong>, we want to catch up on that this time and therefore talk a bit about popular buzzwords like “Deployment Pipeline” and “Branching”. This might be especially useful, if you want to use the CI methodology for your next project but have to convince your team members of the benefits at first. This post is more abstract than the others, if you just want to get down to the Jenkins business you might skip it (although we don’t recommend it, since we put a lot of love into writing this).<\/p>\n

<\/p>\n

Reasons for using CD or CI<\/h2>\n

At first we have to differentiate between CD and CI. The term Continuous Delivery<\/strong> got popular through the same-titled book<\/a> by Jez Humble and David Farley (by the way it’s definitely worth a read). As they put it, they took the title from the famous Agile Manifesto<\/strong>, which states: \u201eOur highest priority is to satisfy the customer through early and continuous delivery of valuable software\u201c – which is practically easier said than done. CD therefore describes a methodology on how to build software in a way, that it can be released to production at any given time. It combines development phase, quality assurance and the deployment process aiming for an overall more efficient development process with increased quality. Now CI comes into play. Martin Fowler<\/a> <\/strong>puts it this way: “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day”[1]. Further he continues, that “each integration is verified by an automated build (including test) to detect integration errors as quickly as possible”.<\/p>\n

Following this statement, CI is part of CD. This means that a better level of synchronization between the development team can be achieved, leading to less challenges during the deployment phase. To achieve this, three requirements must be met:
\n1. Tests need to be in place,
\n2. the build should be production ready at any given time
\n3. and there should be version control.<\/p>\n

All this is realized by using a Deployment Pipeline<\/strong>, which breaks the build into different stages.<\/p>\n

\"ci_bild_blog\"<\/a><\/p>\n

The Deployment Pipeline represents the different stages required for quality assurance. Automated and manual tests enable improvements in quality. These tests are being executed successively for every software version. Only if all tests have been successful, the code will be deployed to production.<\/p>\n

The deployment pipeline<\/h2>\n

Development, Test and Production<\/h3>\n

For our post we would like to illustrate a common practice for different deployment environments. We are not going to implement these on a technical level, however we would like to give an exemplary approach. If you somehow become the CTO of a big company overnight, this could be useful for you. We are going to distinguish between three different stages called development<\/strong>, test <\/strong>and production<\/strong>.This setup is quite common amongst software developers, although the names might vary. Other names for the different environments may include, but are not limited to: staging, latest, deploy, preproduction or sandbox. Although there are different names for it, all environments have similar requirements.<\/p>\n

Usually you want an environment that’s  intended to be unstable, in our case this stage is called development<\/strong>. This is the initial stage where the code of the different developers will be integrated and it’s perfectly fine if this environment breaks – how often do you here something like this? Nobody should feel bad if he messes up here, because the motto should be “fail early, fail fast”. We just want to integrate the code as early as possible and get rid of small mistakes and obvious flaws.<\/p>\n

The next stage called test<\/strong> usually involves some sort of approval. We assume that we have imaginary testers that check our application for us once a stable version is available. The idea behind differencing between the stages development<\/em> and test<\/em> is that developers like to break things, testers not so much. Our testers are not only imaginary but also very demanding and a little bit sensitive about their working environment (as testers are) so it would be advisable not to break this stage multiple times on a daily basis. So to make our testers happy and to provide them with a stable work environment we use the test stage.<\/p>\n

And last but not least (for real) we have the production <\/strong>environment. This stage is the real deal! We suppose at this stage people actually are using what we put there, so it would be kind of awesome if our code works and has been tested once it is deployed here. Luckily with our deployment pipeline we already removed small flaws in development<\/em>  and major bugs in test<\/em>, so it should be safe to deploy our code once it has been approved by our testers. If you have read until this point (and thanks if you did!) you should now have a basic understanding of deployment pipelines.<\/p>\n

Branching<\/h3>\n

As we’ve mentioned in the beginning, we would also like to talk about branching<\/em> a little bit. If you are using git<\/a><\/strong> you’ve probably heard of this term. Basically it is about separating your code into different enclosed parts (or branches) and merging them back together. Usually you are working on the master <\/em>branch, but its also a common practice to have dedicated branches for different features, bugfixes or stable versions. This has the advantage of having a branch which represents a stable version and still be able to develop new features without breaking anything in production. Merging branches in git is as simple as running a single command in the shell. Depending on your requirements for branching, your model can become quite complex, as the image below of a popular branching strategy shows.
\n\"git-branching\"<\/a>Source: http:\/\/nvie.com\/posts\/a-successful-git-branching-model\/<\/em><\/p>\n

For our blog series we thought about the advantages of branching in small academic projects and we agreed that this particular strategy is overall too complex and impractical. Still the author describes a simpler branching model, which can be applied for our requirements. Imaging working with a project group of five people on an university project. The professor is very demanding and wants  to see the course project every week to provide feedback to the group. You have been lucky with your other team members, as they are very productive and they contribute a lot to the project. Unfortunately the work they deliver is sometimes a bit rushed and the version you should present every week often breaks. You think to yourself that it would be great if you could have your team contribute in the large amount they currently do and still be able to present a somewhat stable version regularly to the professor. If this is the case, the approach of using a flexible development<\/em> branch and a stable master<\/em> or demonstration<\/em> branch might suit you.<\/p>\n

\"simpler-branch\"<\/a>Source: http:\/\/nvie.com\/posts\/a-successful-git-branching-model\/<\/em><\/p>\n

Your productive team members can still push as much as they want in the development<\/em> branch and as soon as there is a stable version you can quickly merge changes into the master<\/em> branch. Your team members praise you for your knowledge about branching models and the professor is pleased with the stable demo versions. Good thing you read that one blog post with the strange sesame street characters, isn’t it?<\/p>\n

What’s coming in the next episode?<\/h1>\n

As this post was rather abstract, in the next episode we will jenk’ things up and show you how to create jobs and deploy your code with Jenkins.<\/strong><\/p>\n

Blogpost by Thomas Derleth (td036), J\u00f6rg Einfeldt (je051), Marc Stauffer (ms445)<\/em><\/p>\n

\n

 <\/p>\n

Read more about “Building jobs with Jenkins and Github” in our part 3<\/a> of the tutorial!<\/p>\n","protected":false},"excerpt":{"rendered":"

  One stage. Two stages. THREE STAGES FOR DEPLOYMENT! \u2014 Count von Count on his deployment pipeline Hi, it’s us again, the guys with the strange idea of using Sesame Street characters in a blog series about CI. Since we didn’t really cover the reasons, why you should use CD \/ CI, we want to catch […]<\/p>\n","protected":false},"author":11,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[659,650,651,2],"tags":[],"ppma_author":[691],"class_list":["post-305","post","type-post","status-publish","format-standard","hentry","category-devops","category-scalable-systems","category-system-designs","category-system-engineering"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":3491,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/31\/continuous-integration-deployment-for-a-cross-platform-application-part-2\/","url_meta":{"origin":305,"position":0},"title":"Continuous Integration & Deployment for a Cross-Platform Application – Part 2","author":"Tobias Eberle, Marco Maisel, Tobias Staib, Mario Walz","date":"31. March 2018","format":false,"excerpt":"In the first part we pointed out how we set up the infrastructure for our CI system. Now we would like to explain how we build a pipeline for our cross-platform application and what features of GitLab CI we made use of. Building a Pipeline in GitLab CI Our first\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/flora-app.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":26965,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/02\/28\/wie-baut-man-eine-ci-cd-pipeline-mit-jenkins-auf\/","url_meta":{"origin":305,"position":1},"title":"Wie baut man eine CI\/CD Pipeline mit Jenkins auf?","author":"Cedric Gottschalk","date":"28. February 2025","format":false,"excerpt":"Im Rahmen der Vorlesung \"System Engineering und Management (143101a)\" haben wir es uns zum Ziel gesetzt, mehr \u00fcber CI\/CD Pipelines zu lernen und eine eigene Pipeline f\u00fcr ein kleines Projekt aufzusetzen. Wir haben uns dabei entschieden, Jenkins f\u00fcr die CI\/CD Pipeline einzusetzen und eine kleine ToDo App mit dem Framework\u2026","rel":"","context":"In "System Engineering"","block_context":{"text":"System Engineering","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/system-engineering\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":3496,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/ci-cd-with-gitlab-ci-for-a-web-application-part-1\/","url_meta":{"origin":305,"position":2},"title":"CI\/CD with GitLab CI for a web application – Part 1","author":"Nina Schaaf","date":"30. March 2018","format":false,"excerpt":"Introduction When it comes to software development, chances are high that you're not doing this on your own. The main reason for this is often that implementing components like UI, frontend, backend, servers and more is just too much to handle for a single person leading to a slow development\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"Shaky architecture","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/01_shaky-architecture-300x106.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":382,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/02\/21\/wrap-up-seeing-the-bigger-picture-part-5\/","url_meta":{"origin":305,"position":3},"title":"Jenkbird – Wrap up & seeing the bigger picture – Part 5","author":"J\u00f6rg Einfeldt","date":"21. February 2016","format":false,"excerpt":"Kchhhhhh, Kchhhhhh, Kchhhhhhh... - Ernie on companies without CI Hello internet and welcome to the last part of our\u00a0tutorial series about\u00a0Continuous Integration, Code Deployment and Automated Testing with Jenkins. If you arrived at this post and have read all the others we are very proud of you, hope you enjoyed\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"bert","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2016\/02\/bert-186x300.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":5163,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/migrating-to-kubernetes-part-1-introduction\/","url_meta":{"origin":305,"position":4},"title":"Migrating to Kubernetes Part 1 – Introduction","author":"Can Kattwinkel","date":"24. February 2019","format":false,"excerpt":"Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat Introduction The great challenge of collaborative working in a software developer team is to enable a high level of developer activity while ensuring a high product quality. In order to achieve this often CI\/CD processes are utilized. Talking about modern development techniques\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":3503,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/ci-cd-with-gitlab-ci-for-a-web-application-part-2\/","url_meta":{"origin":305,"position":5},"title":"CI\/CD with GitLab CI for a web application – Part 2","author":"Nina Schaaf","date":"30. March 2018","format":false,"excerpt":"GitLab Our first approach was to use the existing GitLab instance of HdM for our project. For them, a shared runner was already defined on which we could run our jobs, so we were able to focus on the CI process itself. This plan worked out at first. We simply\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"Shaky Pipeline GitLab","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":691,"user_id":11,"is_guest":0,"slug":"je051","display_name":"J\u00f6rg Einfeldt","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/a9c90222aff9d0c74c3c5634b74ead017644b533154f1f72047c3cdb73c3dbe2?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=305"}],"version-history":[{"count":17,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/305\/revisions"}],"predecessor-version":[{"id":24656,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/305\/revisions\/24656"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=305"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}