This tutorial is adapted from the Web Age course https://www.webagesolutions.com/courses/WA3212-ci-cd-with-gitlab.
1.1 Foundation of Agile AppDev
Agile Development begins with Extreme Programming (XP). It was invented/Promoted by Kent Beck and associates.
Beck describes XP as:
- A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect
- A body of practices proven useful in improving software development.
- A set of complementary principles, intellectual techniques for translating the values into practice, useful when there isn’t a practice handy for your problem.
- A community that shares these values and many of the same practices.
1.2 Extreme Programming
As time went on, people took inspiration from XP and developed other approaches with much the same goals:
- Speed
- Include the Customer Early
- Don’t wait until you understand the entire problem – you’ll understand it while you fix it
- Deliver usable value at every iteration
- Make reasonable use of modeling and development tools
1.3 Agile Development
Two themes emerge from XP and Agile Development
- Trust -Vendor, customer, managers, developers all need to trust each other
- Automation- If we’re going to go fast, we need tools that make it easy to produce software
Trust is a social problem – solution is all about different approaches to process, requirements gathering, project management, etc. Automation is about tools – and Continuous Integration is a primary tool of Agile Development.
1.4 What is Continuous Integration (CI)
“Integrate and test changes after no more than a couple of hours.” Beck & Andres “Extreme Programming Explained”
- Integrate and build the complete product, atomic build product
- If a website, build the website packaging, e.g. .NET, J2EE EAR
- If a Javascript development, package the scripts and any configuration files
Purposes
- You find out quickly about integration problems
- Immediately evident if a code change “breaks the build”
- Prevents a long drawn-out integration step at the end of code changes
- Should be complete enough that eventual first deployment of the system is “no big deal”.
Usually, CI goes along with Test-First design and automated QA- Run the unit-test suite and smoke testing to ensure the build isn’t broken.
Clearly, automatic build is a prerequisite. So, we need a build system – Maven for instance.
CI can be synchronous or asynchronous:
- Asynchronous – Integration happens automatically on code committal
- Synchronous – Trigger the build manually after a development session
Side Effects
- Generate development reports
- Install to QA, User Test, etc
- Always have an install-able artifact
It’s a great time to generate development metrics- E.g. Code Coverage, Standards Compliance, Static Analysis
1.5 Typical Setup for Continuous Integration
1.6 Setup Notes for Continuous Integration
Notes:
- CI system gets the code directly from version control
- Build is independent of any local artifacts that are on the developer’s machine
- Controlled links to corporate repository and Maven Central
- Goal is to ensure that the package can be built from the corporate repository
Jenkins, a popular CI tool,can have connections to a deployment environment
- Production Staging
- User Acceptance Testing
- QA
- Load Test
- Etc…
- More info to follow…
1.7 CI with Artifact Management
1.8 What is Continuous Delivery (CD)?
- Using the definition from DevOps thought leader Martin Fowler
- Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
- You’re doing continuous delivery when:
- Your software is deployable throughout its life cycle
- Your team prioritizes keeping the software deployable over working on new features
- Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
1.9 Why Continuous Delivery?
CD extends CI into readiness for deployment and operations
- Agile/XP speeds up the development process
Nonetheless, Agile/XP releases fit into the standard Software Development Life Cycle
1.10 DevOps and Continuous Delivery
Managing deployments and development across horizontally-scaled environments is complex
- We have to deploy more than one server/image/container
- Requires tight control of the process
- Requires automation of development, deployment, and monitoring
- Along with the technologies of virtualization, cloud, etc.
This is the central theme of DevOps – Integrated provision of services using appropriate technology and processes. Deploy software as fast as we create it, while maintaining quality, traceability, and accountability.
1.11 Continuous Delivery Challenges
- More than one department/group involved, not just Developers -QA, Compliance, Business Customers, etc
- CI job takes a few minutes, CD process could extend over days – Could also include human input, manual tests, acceptance tests, etc
Extended cycle means we have multiple process instances “in flight”- “Version 6” part-way through User Acceptance Testing, while work continues on “Version 7”
Multiple resources and test/deployment environments involved
- “Version 6” goes on to Performance Validation
- “Version 7” moves into User Acceptance Testing
- Meanwhile, development gets going on “Version 8”
1.12 Continuous Delivery vs Continuous Deployment
1.13 GitLab CI/CD
GitLab CI/CD is a tool for software development using the continuous methodologies:
- Continuous Integration (CI) – Each change submitted to an application, even to development branches, is built and tested automatically and continuously. These tests ensure the changes pass all tests, guidelines, and code compliance standards established for your application
- Continuous Delivery (CD) – Checks the code automatically, but it requires human intervention to manually and strategically trigger the deployment of the changes
- Continuous Deployment (CD) – Instead of deploying your application manually, you set it to be deployed automatically. Human intervention is not required
https://docs.gitlab.com/ee/ci/introduction/index.html#continuous-integration
1.14 Running GitLab
- You can run GitLab from the Web UI or via command-line
- You can set up distributed instances that cooperate on building software
- Can set up jobs by adding CI/CD configuration file to a project – Jobs have specific tasks, like testing
- Target specific branches and tags by scheduling pipelines
The GitLab Web UI Interface
Alternative is to use the command-line interface, replace “accountname” with your own account
git push –set-upstream git@gitlab.com:”accountname”/$(git rev-parse –show-toplevel | xargs basename).git $(git rev-parse –abbrev-ref HEAD)
1.15 Creating a GitLab Project
Use the dropdown menu items
As mentioned previously, there is a choice of five ways to create a project
1.16 GitLab via YAML Templates
YAML syntax is used to create and edit templates
stages: # List of stages for jobs, and their order of execution
-build
-test
-deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
-echo “Compiling the code…”
-echo “Compile complete.”
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
script:
-echo “Running unit tests… This will take about 60 seconds.”
-sleep 60
-echo “Code coverage is 90%”
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
-echo “Linting code… This will take about 10 seconds.”
-sleep 10
-echo “No lint issues found.”
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when both jobs in the test stage complete successf
ully.
script:
echo “Deploying application…”
echo “Application successfully deployed.”
1.17 Summary
- Continuous Integration and Continuous Deployment are powerful tools for agile software development
- GitLab is gaining popularity as a CI/CD tool
