Web Development Company in Pune: How a Professional Website Deployment Works (Staging, Git, Backups and Rollback)

Web Development Company in Pune: How a Professional Website Deployment Works (Staging, Git, Backups and Rollback)

A professional website deployment means every change is built and checked on a private copy of your site (staging), recorded in version control (Git) in a repository you can access, released to the live site by a repeatable set of steps, and protected by a fresh backup and a rollback you have actually tested. If a web development company in Pune edits your live site directly over FTP or from the WordPress dashboard, it is not doing this, however good the design looks. The difference rarely shows on a normal day. It shows on the day an update breaks the checkout, the contact form or the whole homepage, and someone has to bring the old version back in minutes rather than days.

This article is for business owners and marketing managers who hire a developer or agency and want to know what to expect and ask for, without becoming technical. It covers staging versus production, Git and who should own the repository, the steps of a release, a pre-release checklist, backups and rollback, WordPress traps, release notes and questions for a vendor. Technical facts come from the WordPress developer documentation, the Git documentation and Google Search Central, read in October 2026; those pages change, so verify the live version. Where I describe general practice rather than a documented rule, I say so. The worked example is hypothetical, not a client case. This article does not cover payments, shipping or tax.

What to expect from a web development company in Pune on deployment

Plugin updates that quietly break a form, live edits that a later developer overwrites, and code that exists only on one laptop all happen without bad intent. They happen when changes have no controlled path to the live site. That is a fair thing to ask about when you shortlist a web development company in Pune.

Staging and production: two copies of your site, two different jobs

Production is your live site, the one customers and Google see. Staging is a separate copy, on a different address, where changes are built and tested before they touch production. A third environment, usually called local or development, is the developer's own machine.

A few properties make staging useful rather than decorative:

• It resembles production. Same PHP version, same database engine, same plugins and theme versions. A staging site on a different server configuration can pass every test and still fail live. Ask what staging runs on.

Keeping staging out of Google

A staging site that gets indexed can compete with your real site and expose unfinished pages. Google's documentation on blocking indexing says to use a noindex robots meta tag or an X-Robots-Tag HTTP header, and that Google does not support a noindex rule inside robots.txt. It also warns that if robots.txt blocks a page, the crawler never sees the noindex instruction, so the page can still appear in results if other pages link to it. The practical points: put the staging copy behind a password or login so crawlers cannot reach it at all, and also make sure a staging "discourage search engines" setting does not get copied to production on release. That second mistake, a live site that still tells search engines to stay away, is a classic after a launch. If organic traffic matters to you, our SEO service work includes checking this at every release.

Git in plain language: what it is and who should own it

Git is a version control system. The Git documentation describes it as storing data like a series of snapshots of the project: each commit records what all the files looked like at that moment. It also says everything in Git is checksummed before it is stored, so it is impossible to change the contents of a file or directory without Git knowing about it. The same page notes that nearly all Git actions only add data, which makes it hard to lose committed work, "especially if you regularly push your database to another repository". That last part matters for you: a repository that exists only on one developer's laptop is not a safe copy.

What you get from Git, in business terms:

• A history of who changed what, when, and why. Each commit has an author, a date and a message.
• The ability to undo. The Git documentation describes git revert as recording new commits that undo the changes of earlier ones, leaving the existing history intact. The same page contrasts it with git reset, which discards work and is better used on local commits that have not been shared. For a shared live branch, revert is the safer tool.

Who should own the repository

This is a contract point, not a technical one. There are three common arrangements:

1. The repository is in your own account (on GitHub, GitLab or Bitbucket), and the agency is added as a collaborator. This is the cleanest. If you part ways, you remove their access and you keep everything.
2. The repository is in the agency's account, with an agreement to transfer or mirror it at handover. Workable, but write the handover into the contract, with a date and format.
3. There is no repository. Changes are made on the server. Treat this as a red flag for anything beyond a small brochure site.

Our guide on what you should receive on launch day and own afterwards goes through domain, hosting, licences and code ownership in detail. For this article the short rule is: ask to see the repository, and ask whose name is on the account.

What a release actually looks like, step by step

The sequence below is a reasonable baseline rather than a standard; a good vendor can explain its own version in a few minutes.

1. Change is requested and scoped. Written down: what, why, which pages are affected, who approves. This is where change requests and scope creep get caught.
2. Work is done on a branch. The developer builds the change locally or on staging, separate from the main branch.
3. Staging deployment. The change is placed on staging, with the database and uploads refreshed from production if the change depends on them.
4. Testing on staging. The checks below, ideally by someone other than the author. You or your team approve the result in writing, even by email.
5. Production backup. A fresh backup of database and files, taken immediately before the release and confirmed to exist.
6. Release. The code moves to production, either by an automated pipeline or by a documented manual process. Some changes need a short maintenance window.
7. Post-release checks. The same key paths tested on the live site: homepage, forms, search, key landing pages, and the thing that changed.
8. Monitoring period. The developer watches error logs and uptime for a stated period, and you know whom to contact.
9. Release note. What changed, where, and how to roll back.

A pre-release checklist you can ask to see

You do not have to run these checks yourself. You should be able to ask for the checklist and see that it was filled in. A baseline for a typical business website:

Functionality

• Every form submits, the confirmation page shows, and the notification email actually arrives in the inbox (not only in a log).
• Phone, email and WhatsApp links work on mobile.
• For online stores: add to cart, cart edits and the checkout path reach the final step in test mode.

Search and tracking

• Page titles, descriptions, canonical tags and the robots setting match production's intended values, and the staging noindex setting has not come across.
• Analytics and advertising tags fire once, on the right pages, and are not firing from staging.

Safety

• A backup taken just before release, with its location and time written down.
• The rollback step is known and the person who would do it is available.

Backups and rollback: the part most vendors skip

The two words are often used as if they were one. They are not.

• A backup is a copy of your data that exists independently of the live site.
• A rollback is the act of returning the live site to a known good state after a release goes wrong.

You need both, and the second depends on the first being genuine.

What the WordPress documentation says about backups

The WordPress developer documentation on backups says a typical WordPress site has two parts, the database and the files, and that you need both to fully restore it. Files include core, plugins, themes and uploads; the database holds posts, comments and other generated data. It suggests weekly backups for smaller sites and daily for high-activity ones, advises backing up the database regularly and always before an upgrade, and recommends keeping several recent backups in different locations, such as the hosting server, cloud storage and a local computer. It also says that if you use automatic backups you should periodically make a manual one to confirm the automated process works.

Notice what the page does not describe: a procedure for testing a restore. That gap is where many sites get caught. A backup you have never restored is a hope, not a safeguard. Typical failure points are a backup that covers files but not the database, a backup stored only on the same server that has just failed, an incomplete archive, and credentials needed for the restore that nobody has.

Rollback options, from small to large

The right rollback depends on what broke. For a code change in the theme or a custom plugin, revert the commit in Git and redeploy the previous version, which is the fastest and cleanest route. For a plugin update, reinstall the previous plugin version or restore the plugin folder, remembering the update may already have changed the database. For a core or database change, restore the pre-release backup of files and database. A full restore also rolls back anything created after the backup, such as orders and form entries, so a good vendor plans to export those first and releases at quiet hours.

WordPress-specific cases

WordPress mixes code (theme, plugins) and content (the database) that change independently, which makes deployment less tidy than a pure code project.

Plugin and core updates on staging first

WordPress's own upgrade documentation, for a manual core update, tells you to back up the database and all files including .htaccess, and says verifying that the backups are usable is essential. It lists deactivating all plugins before the manual process. It also describes automatic background updates: minor core updates are enabled by default, major core updates are enabled by default on fresh installs from WordPress 5.6, and plugin and theme auto-updates are off by default except in special cases such as security patches. The page does not mention staging at all; that is a practice the documentation leaves to you.

My practical position, which is general practice and not a WordPress rule: for a brochure site with a handful of well-known plugins, applying minor updates after a backup and a quick check can be reasonable. For a site with a store, a booking system, a membership area or custom code, test updates on staging first, because a plugin can interact with others in ways its changelog does not mention. Security updates are the exception where speed matters; ask your vendor how quickly they apply them and how they test. The website maintenance and support guide explains what an annual maintenance contract should cover.

The database problem: content moves in one direction, code in another

In a Git-based flow, code goes from staging to production. But your content, such as new blog posts, orders and form entries, is created on production. If someone copies the staging database over production to bring a new page across, every post, order and enquiry made on production since the copy was taken is overwritten. This is the most common serious mistake in WordPress deployment.

Safer patterns:

• Code goes up, content comes down. Code and configuration deploy from staging to production. A fresh copy of the production database is brought down to staging before testing, never the reverse, unless the change is a planned migration with a content freeze.

Changing URLs: serialized data and the GUID

When a database is copied between addresses, such as a staging domain and the live domain, stored URLs must be updated. WordPress's migration documentation warns that a plain search and replace can cause issues with data serialization, because some themes and widgets store string lengths tied to the URL. It recommends tools built for this: the Better Search Replace or Velvet Blues Update URLs plugins, WP-CLI's search-replace command, or the Interconnectit script for experienced developers. It also says in strong terms never to change the contents of the GUID column. The WP-CLI documentation says search-replace handles PHP serialized data, switching to PHP processing for columns that contain it, offers a precise mode that forces PHP processing for all columns, and has a dry-run option that reports what would change without saving anything. It also shows how to skip the guid column.

How to read a release note

A release note is the short record that comes with each deployment. Most vendors either skip it or write one so vague that it says nothing. A useful one has:

• Date, time and who released.
• What changed, in plain terms, with page names or URLs: "contact form now sends a copy to the sales address" rather than "form improvements".
• What was not changed, where it could be assumed otherwise.
• Version references: the Git commit or tag, and plugin or core version numbers if updates were part of it.
• Tests done and by whom.
• Backup reference: where the pre-release backup is and its timestamp.
• Rollback method and approximate time to execute.
• Known issues and follow-ups.

A worked example: a Pune clinic's appointment-request site

This is a hypothetical example for illustration, not a client case. A multi-doctor clinic has a WordPress site with a doctors directory, an appointment-request form that emails the front desk, and a small blog. It wants to add online request fields for a new department and update a form plugin that has a security fix.

Without a process. The developer logs into the live dashboard on a weekday morning and updates the plugin. The form template, which relied on an old field name, now sends emails with a blank department field. The front desk receives empty requests for a week and calls patients back from memory. When the clinic complains, the developer cannot say what the previous plugin version was, there is no backup from before the change, and the fix is attempted live and made worse.

With a process.

1. The new fields and the plugin update are scoped as one release, with a written approval from the clinic manager.
2. The developer copies production to staging, behind a login and set not to be indexed, and updates the plugin there.
3. The tester finds the blank department field, and the template is adjusted on a Git branch and reviewed.
4. The checklist is run: the form sends, the email arrives at the front desk inbox with the department filled in, the thank-you page shows, the mobile layout holds, and analytics is not firing from staging.
5. On the day, in a quiet window, a fresh backup of files and database is taken and confirmed. The changed theme template is released from the main branch, and the plugin is updated on production.
6. The team repeats the form test on the live site with a real submission and removes the test entry.
7. Rollback was defined beforehand: revert the template commit and reinstall the previous plugin folder, with a full restore only as a last resort. Because the clinic receives requests all day, the plan also says to export the form entries first, so that no real requests are lost in a restore.

Questions to ask a vendor

Use these in a call or in a written questionnaire. The aim is not to catch the vendor out. A good team will answer calmly and show you evidence.

1. Is there a staging site for my project, and what does it run on? Is it on the same server, or a separate one with matching versions?
2. Is my staging site private and kept out of search? How?
3. Where is the code kept, and in whose account? Can I be made an owner or have read access?
4. How do changes reach the live site: manual, scripted or automated? Can you show me the steps written down?
5. When is a backup taken, where is it stored, and how long is it kept? Is it off the live server?
6. When did you last restore one, and how long did it take? Will you do a restore test as part of the engagement?
7. What is the rollback plan for a bad release, and who can execute it on a weekend?
8. How do you handle the database between staging and live? What stops staging content overwriting live orders or enquiries?
9. What access do you hold, and what happens to it if we stop working together?

Working with Govindani Infotech

Govindani Infotech is a web design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. If you are comparing agencies, bring the questions above to us as well, and expect us to answer them with the actual screens rather than slides. We can also review the way your current site is updated, looking at where the code lives, whether there is a staging copy, and whether the last backup can be restored, and tell you plainly what needs fixing before the next big change.

For a new build, our website creation work is where staging, the repository and the release process are agreed in writing at the start; if you run a store, the ecommerce service page covers the additional care that carts and orders need. To talk it over, use the contact page or message us on WhatsApp.

Frequently Asked Questions

What is a staging site and do I really need one?

A staging site is a private copy of your website where changes are tested before they go live. For a small brochure site that rarely changes you can sometimes manage without one, but any site with forms, a store, bookings or custom code benefits from it, because a failed update is then found on the copy and not by your customers.

Who should own the Git repository for my website?

Ideally it sits in an account the business controls, such as your own GitHub or GitLab organisation, with the agency added as a collaborator. If the agency hosts it, the contract should say when and how the repository will be transferred to you.

Is an automatic backup enough?

Not by itself. WordPress documentation says a restorable WordPress backup needs both the files and the database, and recommends making an occasional manual backup to confirm the automatic process works. Beyond that, the backup should be stored away from the live server, and a restore should be tested at least once so you know it works and how long it takes.

What is the difference between a rollback and a restore?

A rollback is returning the live site to its previous working version after a bad release, often by reverting a code change or reinstalling the earlier plugin version. A restore means bringing back a full backup of files and database, which can also remove any data created after the backup, such as new enquiries.

Can I copy the staging database to the live WordPress site?

Usually not. It overwrites everything created on the live site since the copy was taken, including enquiries and orders. Deploy code from staging to live, and bring the live database down to staging for testing; if URLs must change, use a serialization-aware tool such as WP-CLI search-replace after a dry run, and never alter the GUID column.

Sources:

• https://developer.wordpress.org/advanced-administration/security/backup/
• https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
• https://developer.wordpress.org/advanced-administration/upgrade/migrating/
• https://developer.wordpress.org/cli/commands/search-replace/
• https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
• https://git-scm.com/docs/git-revert
• https://developers.google.com/search/docs/crawling-indexing/block-indexing