Commit c0ce15d1 authored by soumyadip's avatar soumyadip

Removing old folder

parent 4bf15c66
.. contents::
Why Error-Tracking is required
- Getting rid of risks to deploy code with bugs
- Helping QA with testing code
- Getting a quick notification about troubles
- Allowing a fast turnaround with bug fixes
- Receiving a convenient display errors in admin panel
- Sorting the errors by user / browser segments
Implementation of Error-tracking,
Deployed resource, [ or Register]
Gitlab Integration
Gitlab Integration information can be found at,
\ No newline at end of file
Gitlab to Github pipeline
.. contents::
Code Pipeline
There are teams/projects that need their public facing code to be on Github and their in-house code to be in Gitlab.
The Gitlab to Github automated code pull/push can be set up and found at,
Release Automation
There are cli tools available to automate release of code from gitlab pipelines to any gitlab or github project by
the use of auth token.
Tools used:
- Github -
- Gitlab -
The below .gitlab-ci.yml demonstrates release automation of binary files generated on 'dist/' artifact from build(not shown) stage.
This implementation has been taken from
.. code:: yaml
stage: release
image: python
- pip3 install gitlab-release
- cd dist/
- gitlab-release --server ${GITLAB_SERVER}/${IMAGE_GROUP}/${IMAGE_PROJECT} --project_id ${IMAGE_PROJECT_ID} --description ${CI_REGISTRY}/${IMAGE_GROUP}/${IMAGE_PROJECT}/${IMAGE_NAME}:${CI_BUILD_TAG} dsds-client
# Must include files passed to gitlab_release
- dist/
- tags
stage: release
image: debian
- apt-get update && apt-get install -y hub gettext-base
- mkdir -p /root/.config
- envsubst < hub.template > /root/.config/hub
- hub clone --bare https://${GITHUB_USER}:${GITHUB_TOKEN}${GITHUB_REPO}.git cloned-project/
- mkdir -p cloned-project/dist
- cp -r dist cloned-project/
- cd cloned-project
- '[ -z "${RELEASE_MESSAGE}" ] && export RELEASE_MESSAGE="${CI_COMMIT_REF_NAME}\n\nRelease-${CI_COMMIT_REF_NAME}"|| echo "Release message:\n${RELEASE_MESSAGE}"'
- echo -e ${RELEASE_MESSAGE} > release_mssg.txt
- cat release_mssg.txt
- 'hub release create -F release_mssg.txt -a "dist/dsds-client#dsds-client-centos" ${CI_COMMIT_REF_NAME}'
# Must include files passed to gitlab_release
- dist/
- tags
Gitlab DevOps
This document is based on Gitlab instance deployed in EBI by web production team. The reference of the instance can be found `here <>`_.
.. contents::
- Should have EBI Gitlab account
- Basic knowledge on Docker/Kubernetes
DevOps - Sounds familiar?
**DevOps** can be best explained as people working together to build, deliver,
and run resilient software at the speed of their particular business. DevOps
enables software development (**Dev**) and operations (**Ops**) teams to accelerate
delivery through automation, collaboration, fast feedback, and iterative improvement.
For more, check
Why Gitlab for DevOps?
There are a lot of DevOps tools out there. As a single application for the entire DevOps
life cycle, GitLab can remove the pain of having to choose, integrate, learn, and maintain
the multitude of tools necessary for a successful DevOps tool chain.
For more, check
Auto DevOps
Auto DevOps provides pre-defined CI/CD configuration which allows you to automatically detect,
build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools,
Auto DevOps aims to simplify the setup and execution of a mature & modern software development
With Auto DevOps, the software development process becomes easier to set up as every project can
have a complete workflow from verification to monitoring with minimal configuration. Just push your
code and GitLab takes care of everything else. This makes it easier to start new projects and brings
consistency to how applications are set up throughout a company.
As you can expect, it is not possible for Gitlab to detect and setup deployment for each and every possible
application. There are certain expectation from application that Gitlab required it to be adhered to for Auto-DevOps
to be working without any manual scripting, details on this later. Further, having Gitlab doing all the build and deployment
might not be suitable use-case for everyone.
- GitLab Runner
- Base domain
- Kubernetes
- Prometheus
For more,
Although it is called *Auto* DevOps, there are some assumptions have been made for Auto Deployment to be working for the application.
The assumptions(and experiences!) are as follows,
- Application should be listening on 5000 port
- Better to write your own Dockerfile, things generally don't work well with hiroku build packs
You can customize some of the parts, more details on
You can find the implementation of Auto-DevOps in,
and sample pipeline in the same project,
Security Dashboard, containing test result after running Auto-DevOps tests,
Metrics of the running service can be found at,
.. contents::
Why Tracing is required
As on-the-ground microservice practitioners are quickly realizing, the majority of operational
problems that arise when moving to a distributed architecture are ultimately grounded in two
areas: networking and observability. It is simply an orders of magnitude larger problem to network
and debug a set of intertwined distributed services versus a single monolithic application.
What Tracing addresses
- Distributed transaction monitoring
- Performance and latency optimization
- Root cause analysis
- Service dependency analysis
- Distributed context propagation
Implementation of tracing (Opentracing - Jaegar) can be found in,
The Jaegar UI is available at,
Gitlab Integration
Gitlab Integration information can be found at,
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment