Category:DESHWAL: Difference between revisions

Training on Deshwal Project Part 1. Dated 01 JULY 2025 - Tetra Support Staff - TUSHAR[edit]

Video summary: "DeshwalProject Training Part 1" -- a Hindi-language architecture and setup walkthrough for the Deshwal client's LAMP-stack environment (Linux/Apache/PHP/MySQL, plus Jenkins), which has separate Production and Staging environments. Architecture, top to bottom: a public IP/domain NATed to a private IP shared by two DMZ-facing reverse-proxy servers (Proxy 1 primary, Proxy 2 secondary) using keepalived for a floating/virtual IP, so both proxies can receive traffic simultaneously based on load, each configured to prefer its local app server (App1) and fail over to App2 only if App1 becomes unavailable for a defined window; two application servers (App1 primary, App2 secondary) behind the proxies, where App1's attached disk (holding `/data` and `/backup`) is shared out to App2 via NFS -- note this is a direct NFS export from App1 itself, not a separate third-party NFS appliance; and two database servers (DB1 master, DB2 slave) with one-way replication, where App1 always writes to DB1 and manual promotion of DB2 to master is required if DB1 fails. External backups are handled by a separate team using a Commvault backup agent. The session then walks through the actual proxy-server build: installing/upgrading Apache, a redirect vhost that forces all HTTP requests to HTTPS, and a separate reverse-proxy vhost implementing the App1-primary/App2-fallback routing, with the firewall restricted to ports 80/443/56 and keepalived installed only on Proxy 1 in production. On the app server side: mounting the dedicated data disk, storing actual application data under `/data` and symlinking it into the Apache document root (with root ownership, SGID, and group-based permissions so the Apache user can read/write without owning the files), editing the app's DB-connection config, installing PHP and its required packages (noting Ubuntu bundles PHP with Apache, requiring an Apache restart to apply config), and installing phpMyAdmin from a downloaded tarball into a defined path with its own vhost, read-only S3-backed file storage for downloadable assets, and appropriate permissions.

Training on Deshwal Project Part 2. Dated 02 JULY 2025 - Tetra Support Staff - TUSHAR[edit]

Video summary: "Deshwal Project Training Part 2" -- continues directly from Part 1, this time covering the operational deployment/release process rather than initial setup. Walks through the staging deployment procedure: VPN into the private staging server IP, run a pre-existing sync script to keep required files intact, then use Jenkins (a free-style project pulling from a specific Git branch/repo via stored credentials, deploying into the document root) to trigger a build -- explicitly warning never to click "Build Now" or "Delete Now" except when specifically instructed, since it deploys whatever code state currently exists, clean or not -- and finally verify the deployed site loads correctly via its URL/credentials. Production deployment mirrors staging but with different server IPs, plus an extra step: SSH to the F1 production server to run a script that syncs a specific set of files from staging into production, since some config isn't carried automatically. Covers a one-time full config backup already taken to Tetra's own S3 bucket (with the exact command used and date logged) as a safety net, and a separate, ongoing CommVault-driven backup regime run by the client's own backup team: proxy servers get a one-time backup only (rarely change), app servers get a weekly snapshot (Sunday 1am, 30-day retention, 4 copies always available), and the DB servers get both incremental backups (daily Monday-Saturday, 7-day rolling retention) and full weekly backups (Sunday 1am, 14-day retention, 2 copies), including filesystem and database data in both. Lists CommVault-side contacts to reach for backup mode changes or restores, and the client-side point of contact for general project queries. Also covers setting up VPN access via a provided client installer, and briefly introduces the Nagios-based monitoring setup on Tetra's monitoring server, which pulls metrics from each server via a proxy-server relay using custom host/service/command config files (also backed up to S3 for reuse in future deployments).

Deshwal live activity from dev to staging-sify[edit]

        http://172.16.20.21:8080
        username - Tushar
        password - Kalyan123tush@r
        login
       click DeshwalNew
       click Build Now

Deshwal live activity from staging-sify to prod-sify[edit]

        app1
        http://172.16.20.16:8080
        username - Tushar
        password - Kalyan123tush@r
        login
        click DeshwalNew
        click Build Now

        app2
        http://172.16.20.17:8080
        username - Tushar
        password - Kalyan123tush@r
        login
        click DeshwalNew
        click Build Now

Training on Deshwal Live Activity Via Jenkins. Date 11 July 2025- Tetra Support Staff - TUSHAR[edit]

Video summary: "Deshwal Live Activity Via Jenkins (updated 11 July 2025) - TUSHAR" -- a focused, practical live-demo recording of the actual staging and production deployment steps introduced in Part 2, done by a different presenter (Tushar) as a refresher. Connects via a Deshwal-specific VPN profile, opens Jenkins on the staging server (port 8080), clicks the "DeshwalNew" job and "Build Now," confirms a green/successful build, and repeats the same steps against both production application servers (App1 and App2, each running its own Jenkins instance on the same default port) since the environment has two app servers requiring independent builds. After both builds succeed, verifies the deployment by logging into the staging and production site URLs directly with admin credentials to confirm no errors (e.g. database connectivity) before considering the release complete, followed by a status update to the team. Also opens up the Jenkins job's actual build configuration for a deeper explanation: it pulls from the master branch of the Deshwal Git repo using stored credentials, whichever code developers have most recently pushed; the build step is a shell script that first fixes file/folder ownership and permissions, `rsync`s the pulled code into the Apache document root while excluding an "intact" folder (config/data files that must survive each deployment and are instead separately synced back in from a preserved backup location), and runs the `rsync`/`chmod`/`chown` operations with `sudo` because the Jenkins service account needs elevated rights for those specific operations -- with a matching `sudoers` entry granting Jenkins passwordless access to exactly those three commands.

Deshwal code revert activity and daily working process from developer side.[edit]

======================================================================[edit]

ONE TIME CHANGES : changes done on Git and Github : git reset --soft <commit-id-previous-version> git checkout -b production git checkout -b staging git reset --soft <commit-id-latest-version>

======================================================================[edit]

REGULAR CHANGES :

Work need to do to Deepika:

======================================================================[edit]

When code is mature on development environment and tested in development, Then need to merge code to staging branch. git checkout staging git merge master NOTE : effect of this will be code will get deployed in staging server. NOTE : NO NEED TO DO ANY WORK TO SERVICE TEAM.

=====================================================================[edit]

When code is mature on staging environment and tested in staging, Then need to merge code to production branch. git checkout production git merge staging

NOTE : effect of this will be code will be get deployed in production server NOTE : NO NEED TO DO ANY WORK TO SERVICE TEAM.

Training on Oxypc CICD Deployment KT DESHWAL. Dated 08 JULY 2026 - Tetra Support Staff - PRASHANT[edit]

Video summary: "Oxypc CICD Deployment KT DESHWAL" -- an English-language KT session on the CI/CD pipeline built for OxyPC, a separate PHP (Yii2 framework) project deployed to `/var/www/html/oxypc`, hosted on GitHub and deployed via Jenkins (chosen over alternatives like GitHub Actions/GitLab CI). Walks through the Jenkins pipeline stage by stage: a checkout-from-SCM stage using stored Git credentials against the main branch (built using Jenkins' "generate pipeline syntax" helper); a code-review/validation stage that runs a PHP lint/syntax check (`php -l`-style check) -- currently commented out on the development pipeline at the developers' request, but still active on staging, demonstrated live by intentionally introducing a PHP parse error and showing the check catch it; a backup stage that snapshots the current deployed code into a dedicated backup directory under `/opt` with its own retention policy before the new code is deployed; the actual deployment stage that syncs the checked-out code to the live path; and a post-deployment stage that emails a designated group (the presenter plus two others) automatically if the build fails. Explains the GitHub webhook integration that makes deployment fully automatic: a developer push to GitHub fires a webhook that Jenkins listens for, which kicks off the entire pipeline (checkout -> validate -> backup -> deploy -> notify) without manual triggering -- noting the presenter doesn't have direct access/credentials to the GitHub webhook config itself (owned by the client's dev team) but can describe the flow. Closes by briefly showing a `sudoers` entry added for the Jenkins user to allow the specific commands the pipeline needs without a password prompt.