Skip to content
Snippets Groups Projects
New issue look: Off

Git-Centric Continuous Delivery

    • Open Issue created by username-removed-1137252 @mariuszluciow

    Hi,

    I'm the technical leader of a platform team from Ocado Technology. We are using GitLab quite extensively, in fact we are looking right now into enterprise edition.

    During the migration from our old CI solution into the GitLab, we prepared series of tutorials (targeted internally). Among them one could be interesting to broader audience - let me know what do you think.

    What is your audience?

    developer with basic GitLab CI experience

    What are the requirements?

    First section describes general concepts. After that there is a working example based on Spring Boot and Maven. Reader doesn't have to know Java nor Maven to understand concept and solutions.

    What's your ETA?

    Week or two.

    Proposal

    Writing sample

    Till now I was writing only internal articles for my company, also doing technical talks in Wrocław. If you will find topic interesting I will try getting approval to share one of the articles.

    Introduction

    The quality of your automation is as much important as the quality of your code. At Ocado Technology we learned, that continuous improvement of you Continuous Delivery is necessary to develop better software. Having all scripts and configurations in order enables us to improve on daily basis. Configuration inside repository, versioned along with the source code and stored in human-friendly format is the de-facto solution for storing and managing automation. That's exactly what GitLab CI provided us with.

    Most people, when migrating from other CI systems, that allow building pipelines, just builds the same process they had previously. Often the flow starts with new commits on master branch, then release and some deployment steps to different envrionments. Nothing wrong with that approach, I started by doing the same, but we can do much better. Often underestimated feature of GitLab CI is possibility to have different pipelines on different repository refs. If we shift our thinking about automation, using this feature we can highly improve visibility and maintainability of our systems.

    Outlines

    [Your article's topic structure. We'll evaluate how you structure your subject in sub-topics, the depth of your content and the logic of your construction. Your outlines should respond: what is required to get started, what problem does your article solve, why is it important, what's the motivation to follow your method.]

    • Introduction - few words of introduction. Describing the problem, which is how to orchestrate Continuous Delivery using GitLab to get maximum visibility and maintainability keeping semantic versioning of the application.
    • Building master based pipeline - this section is to get user started and introduce basic concepts of GitLab CI configuration.
    • Feature Branches - Moving to more advanced configuration, I will introduce how to test, build and deploy application from branches, before merging the code.
    • Release Branches Tags - This is the most interesting section for people having experience with GitLab and Continuous Delivery. My proposal is to forget about Release Branches and move to tags. Thanks to that we will see in GitLab what versions and when have been deployed to the selected environment much better. What is more, it is an unquestionable fact that the code we deployed is exactly what we’ve tested and released.
    • Maintenance Branches - Finally, I will describe concept of having maintenance branches, especially useful for people maintaining libraries. This section will benefit from tag-based deployment approach, making release of bug-fixes much easier.

    Example project

    Not decided yet if its necessary, I might add it later.

    Edited by username-removed-1137252

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply