Integration, Deployment and Web Operations

Introduction

A web page becomes a web application when its structure, presentation, behaviour, and delivery environment work together. HTML defines content and meaning, CSS controls appearance and layout, and JavaScript supplies interaction and application logic. Integration is the process of combining these technologies into a coherent product. Deployment is the process of making that product available to users. Web operations concerns the continuing activities required to keep it secure, reliable, maintainable, and understandable.

For a certificate-level developer, these activities are not optional extensions to programming. A carefully written interface that cannot be built consistently, deployed safely, or maintained by another developer is incomplete. This chapter introduces a practical workflow from project organization and version control through build tools, configuration, hosting, domains, HTTPS, continuous delivery, documentation, and operational improvement.

Learning Objectives

By the end of this chapter, you should be able to:

• integrate HTML, CSS, and JavaScript into a complete small project;
• organize a project using a sensible file and directory structure;
• use Git branches, commits, remotes, and pull requests at an introductory level;
• explain the purpose of package managers and build tools;
• distinguish development, testing, and production environments;
• manage configuration without exposing secrets;
• deploy a static site to a hosting service;
• explain domain names, DNS, HTTPS, and certificates;
• describe the purpose and stages of a CI/CD pipeline;
• produce technical documentation and an operational checklist; and
• identify common deployment, security, accessibility, and maintenance risks.

1. From Individual Files to an Integrated Application

A basic project may contain an HTML document, a stylesheet, and one or more JavaScript files:

project/
├── index.html
├── css/
│   └── styles.css
├── js/
│   └── app.js
├── assets/
│   ├── images/
│   └── icons/
├── tests/
├── README.md
└── .gitignore

The HTML file is the entry point. It should contain semantic elements such as header, nav, main, section, form, and footer where appropriate. CSS should be linked using a link element, and JavaScript should normally be loaded with defer:

<link rel="stylesheet" href="css/styles.css">
<script src="js/app.js" defer></script>

The defer attribute allows the browser to parse the document while downloading the script and executes the script after parsing has completed. This commonly avoids errors caused by JavaScript trying to access elements that have not yet been created.

Integration requires more than placing files in one directory. The developer must ensure that:

1. paths are correct in every environment;
2. HTML elements have stable, meaningful identifiers or classes;
3. CSS rules support the intended responsive layout;
4. JavaScript responds to user events and updates the document safely;
5. assets are available at the paths referenced by the application;
6. the interface remains usable with keyboard navigation and assistive technology; and
7. the application can be tested from a clean installation.

A useful separation of responsibilities is:

JavaScript should not be used to create every element when ordinary HTML can provide the structure. Progressive enhancement is a valuable principle: begin with a meaningful HTML experience, add CSS for presentation, and add JavaScript for enhanced behaviour. This improves accessibility, resilience, and maintainability.

2. A Practical Project Workflow

A small project benefits from an explicit workflow. First define the purpose, users, main tasks, and acceptance criteria. Then create the interface structure, style it, implement behaviour, test it, and prepare it for deployment. Development should proceed in small increments rather than through one large final upload.

A typical sequence is:

1. Create a project directory and initial HTML page.
2. Add semantic structure and placeholder content.
3. Add CSS variables, layout rules, responsive behaviour, and states such as :hover and :focus.
4. Add JavaScript modules or functions for interaction.
5. Test manually in multiple viewport sizes and browsers.
6. Run automated checks, if available.
7. Commit a coherent change to Git.
8. Build or package the application.
9. Deploy to a preview or staging environment.
10. Verify the deployed result and then publish to production.

A useful acceptance criterion is observable and specific. “The form works” is vague. “A user can submit a valid email address, receives a confirmation message, and sees an accessible error when the address is invalid” is testable.

3. Git and Collaborative Workflows

Git is a distributed version-control system. It records changes as commits and permits developers to work on separate branches. A repository contains the project and its history. A remote repository, hosted on a platform such as GitHub, GitLab, or another service, allows collaboration and backup.

Important concepts include:

• Working tree: files currently being edited.
• Staging area: changes selected for the next commit.
• Commit: a named snapshot of staged changes.
• Branch: a movable line of development.
• Merge: combining histories.
• Remote: a shared repository location.
• Pull request or merge request: a reviewable proposal to combine changes.

A basic workflow is:

git init
git add .
git commit -m "Create initial page structure"
git branch -M main
git remote add origin <repository-url>
git push -u origin main

For a new feature, a developer may use:

git switch -c feature/form-validation
# edit and test files
git add js/app.js
git commit -m "Add client-side form validation"
git push -u origin feature/form-validation

Commit messages should describe the change, not merely the activity. “Fix mobile navigation focus state” is more useful than “update files.” Commits should be reasonably small and internally coherent. Do not commit passwords, private keys, large generated directories, or machine-specific settings. A .gitignore file commonly excludes dependency directories, local environment files, logs, and build output when the output is generated during deployment.

A simple team workflow is feature branch → review → automated checks → merge into main → deployment. Branch protection can require review and passing checks before changes enter the production branch. Git is not a substitute for backups, testing, or documentation; it supports them.

4. Packages and Build Tools

A package is reusable software distributed through a package registry. A package manager installs packages, records their versions, and often runs project scripts. In the JavaScript ecosystem, common package managers include npm, pnpm, and Yarn. A project manifest, commonly package.json, describes metadata, scripts, and dependencies.

A conceptual example is:

{
  "name": "task-board",
  "version": "1.0.0",
  "scripts": {
    "dev": "tool dev",
    "build": "tool build",
    "test": "tool test",
    "format": "tool format"
  },
  "dependencies": {},
  "devDependencies": {}
}

The exact commands depend on the selected tool. A lockfile records the resolved dependency versions, helping different machines install a consistent dependency tree. It should normally be committed to version control for an application.

Development dependencies support authoring and testing; production dependencies are needed when the application runs. Some static front-end tools produce a dist or build directory containing optimized files. A bundler may combine modules, transform modern syntax, process CSS, optimize images, and create cache-friendly filenames. Minification reduces unnecessary whitespace and characters, but it does not replace good code design or testing.

Build tools introduce risks as well as benefits. A broken configuration can prevent deployment, a vulnerable package can affect the application, and an outdated plugin may no longer be supported. Use only required packages, review updates, keep lockfiles consistent, and inspect advisories. Never assume that a package is safe merely because it is popular.

5. Environments and Configuration

An environment is a context in which an application is developed or operated. The common categories are:

Configuration includes values that vary between environments, such as an API base URL, feature flag, analytics identifier, or server port. It is often represented through environment variables or platform settings. A local file such as .env.local may contain development values, but it should be excluded from Git when it contains secrets.

A crucial distinction is between a configuration value and a secret. A browser-delivered API endpoint or public application identifier is not secret because users can inspect it. A database password, signing key, private API token, and service credential are secrets and must remain on a trusted server or secret-management system. Any value embedded in front-end JavaScript should be assumed to be visible to users.

Configuration should be validated at startup or build time. Missing required values should produce a clear failure rather than a partially functioning application. Avoid silently substituting production credentials in development or development endpoints in production.

6. Static Hosting, Domains, and HTTPS

A static site consists of files that can be served without server-side code for each request. HTML, CSS, JavaScript, images, and fonts are common static assets. Static hosting is suitable for portfolios, documentation, landing pages, and many client-side applications. It is usually simple, scalable, and inexpensive.

Deployment to static hosting normally involves connecting a repository or uploading a build directory, selecting the output directory, and specifying a build command if required. A platform may provide a temporary subdomain. Before considering deployment complete, verify:

• the correct branch or directory is published;
• the home page loads directly;
• asset paths work on nested routes;
• refreshes do not produce unexpected 404 errors for a single-page application;
• forms and external API requests behave correctly;
• the production build contains no development credentials; and
• the site works on mobile and desktop browsers.

A domain name is a human-readable address such as example.org. DNS translates domain names into records used by clients and hosting providers. An A record maps a name to an IPv4 address, an AAAA record maps it to an IPv6 address, and a CNAME record aliases one name to another hostname. DNS changes may take time to appear because resolvers cache records according to their time-to-live settings.

HTTPS is HTTP carried through a secure TLS connection. It provides encryption in transit, server authentication through a certificate, and integrity protection. A certificate authority validates control of a domain and issues a certificate for an appropriate period. Modern hosting services often automate certificate issuance and renewal.

HTTPS is essential even for apparently simple sites. Without it, users on an untrusted network may have their traffic observed or modified. Mixed content is a problem in which an HTTPS page requests insecure HTTP resources; browsers may block those resources. All resources, forms, and API requests should use secure URLs. Redirect HTTP to HTTPS and configure secure cookies when cookies are used.

7. CI/CD Concepts

Continuous integration (CI) means frequently integrating changes into a shared repository and automatically checking them. Continuous delivery means keeping software in a releasable condition, often with an approval step before production. Continuous deployment goes further by automatically releasing changes that pass the required checks.

A basic pipeline may contain:

commit → install dependencies → lint/format check → test → build → preview → approval → production

Each stage should have a clear purpose. Linting identifies probable code problems and style violations. Tests check expected behaviour. The build confirms that source code can become deployable output. A preview allows human review. Production deployment should be repeatable and preferably reversible.

CI/CD does not guarantee quality. A pipeline can pass while requirements are wrong, accessibility is poor, or a third-party service is unavailable. Automated checks complement—not replace—human review. Pipeline credentials should have the minimum permissions necessary. Logs must not reveal secrets, and deployment actions should be auditable.

A useful operational property is repeatability: the same source revision and configuration should produce the same intended result. Pinning dependencies through a lockfile, documenting commands, and using a clean build environment improve repeatability.

8. Testing, Accessibility, and Security Before Release

Testing should address both expected and unexpected use. Manual testing can examine navigation, layout, form feedback, loading states, empty states, error states, and behaviour on slow connections. Automated tests may check functions, components, links, and build output.

Accessibility is part of functional quality. Use correct heading order, labels associated with form controls, visible keyboard focus, sufficient colour contrast, descriptive alternative text, and buttons for actions rather than clickable non-semantic elements. Do not communicate essential information by colour alone. Test with keyboard navigation and, where possible, a screen reader.

Common front-end security concerns include:

• inserting untrusted strings with unsafe HTML APIs, which can enable cross-site scripting;
• exposing secrets in source code or browser-delivered bundles;
• accepting user input without validation on the server when a server exists;
• loading third-party scripts without assessing their trust and permissions;
• using dependencies with known vulnerabilities; and
• failing to configure appropriate security headers on the hosting platform.

Client-side validation improves user experience but is not a security boundary. A malicious user can bypass JavaScript and send a crafted request directly to a server. Authoritative validation and authorization must occur on the server or service that owns the data.

Performance should also be assessed. Compress images, choose suitable dimensions, defer non-critical work, avoid unnecessary dependencies, and use caching carefully. A cached file with an old filename can remain visible after deployment; content-hashed asset filenames and a controlled cache policy help manage this problem.

9. Technical Documentation and Operations

Documentation transfers knowledge from the original developer to users, reviewers, and future maintainers. A useful README.md should state:

• the project purpose and main features;
• prerequisites and supported runtime versions;
• installation steps;
• development, testing, and build commands;
• environment variables and an example configuration file;
• deployment instructions;
• known limitations;
• accessibility or browser-support notes; and
• contact, ownership, or contribution information.

Operational documentation should answer: How is the site deployed? What should be checked after deployment? Who can change DNS or credentials? How is a rollback performed? Where are logs or hosting events viewed? What happens when an external API fails?

A release checklist may include:

Change logs and release notes are useful even for small applications. They establish what changed and support troubleshooting. Incident notes should record the impact, timeline, cause if known, corrective action, and prevention—not blame.

10. Applied Case: Campus Events Directory

Background

This illustrative case concerns a small campus events directory. Students can filter events by category, view dates and locations, and submit an event suggestion. The first version works on a developer’s laptop but is difficult to deploy and maintain.

Problem

The project has all code in one HTML file, image paths that work only on the developer’s machine, no version history, and an API URL written directly into JavaScript. The production site is hosted through an ad hoc file upload. A refresh on a filtered route returns a 404 error, and the form provides no keyboard-visible focus indication.

Analysis

The project requires integration and operational improvements rather than a complete rewrite. The team identifies the following risks:

• unclear separation between structure, presentation, and behaviour;
• no repeatable installation or build procedure;
• possible exposure of a service credential;
• inconsistent paths in production;
• absent review and testing workflow; and
• accessibility and routing defects.

Approach and Solution

The team separates files into index.html, css/styles.css, js/app.js, and assets. JavaScript is loaded with defer, and event handling uses semantic controls. A package manifest adds development, test, and build scripts. A lockfile is committed, while local environment files are ignored.

The API base URL is configured through the hosting platform’s non-secret build configuration. A private service credential is removed from browser code and moved to a server-side function. A feature branch is created for each change. Pull requests require a successful build and a manual accessibility review.

The hosting platform is configured to publish the build directory. A fallback rule serves the application entry point for client-side routes. The custom domain is connected with DNS, HTTPS is enabled, and HTTP is redirected to HTTPS. The README documents local setup, deployment, environment values, and rollback to the previous successful deployment.

Outcome

The project can be reproduced by a new developer from a clean checkout. Preview deployments allow event organizers to review changes before publication. The production site loads its assets correctly, route refreshes work, and the form gives clear feedback to keyboard users. The team can identify the deployed commit and return to a known working version.

Learning Points

The case demonstrates that deployment quality depends on decisions made during development. File organization, semantic HTML, configuration discipline, version control, testing, and documentation are connected. Static hosting simplifies delivery, but it does not remove the need for security, accessibility, routing, or operational responsibility.

11. Challenges, Limitations, and Contemporary Practice

Static hosting is powerful but has boundaries. It cannot safely store private credentials or directly perform privileged database operations. Dynamic behaviour may require serverless functions, an application server, or a managed backend. Third-party services introduce availability, privacy, pricing, and contractual risks.

Automation can reduce human error but can also spread a defect quickly. A deployment pipeline should include approvals or safeguards appropriate to the project’s risk. Dependency automation should be reviewed rather than accepted blindly. AI-assisted coding can help generate tests, explain errors, or draft documentation, but generated code must be tested, reviewed for licensing and security concerns, and checked against project requirements. AI tools may also receive source code or confidential information; organizational privacy rules must be followed.

Web operations also has an environmental and social dimension. Unnecessarily large media, excessive scripts, and repeated network requests consume energy and may exclude users with limited bandwidth. Performance, accessibility, privacy, and security are therefore quality attributes, not merely optional enhancements.

Best-Practice Checklist

• Keep HTML semantic and CSS organized by responsibility.
• Use small, descriptive Git commits and reviewable branches.
• Commit lockfiles, but exclude secrets and local machine data.
• Document setup, scripts, configuration, and rollback.
• Treat browser-visible configuration as public.
• Build in a clean environment before release.
• Test links, routes, forms, keyboard access, and responsive layouts.
• Use HTTPS and secure all resource requests.
• Give deployment credentials only the permissions they require.
• Monitor changes and record the deployed commit.
• Prefer reversible, repeatable deployments.
• Review dependencies and AI-generated code before use.

Chapter Summary

Integration combines semantic HTML, maintainable CSS, JavaScript behaviour, assets, and tooling into a coherent application. Git provides a history and collaboration model through commits, branches, remotes, and reviews. Package managers and build tools make installation and production preparation repeatable, while lockfiles and dependency review reduce avoidable variation and risk.

Development, preview, and production environments should be distinguished. Configuration must be separated from source code, and secrets must never be placed in browser-delivered files. Static hosting can efficiently serve front-end assets; domains and DNS provide human-readable access, while HTTPS protects communication and authenticates the site.

CI/CD pipelines automate checks, builds, previews, and releases, but automation does not replace human judgement. Testing must include functionality, accessibility, security, performance, and error states. Technical documentation, release records, rollback procedures, and operational checklists make a project maintainable. Effective web operations is therefore a combination of engineering discipline, user responsibility, security awareness, and clear communication.

Key Terms

Git: A distributed version-control system.

Repository: A project directory together with its version history.

Commit: A recorded snapshot of staged changes.

Branch: An independent line of development in a repository.

Remote: A repository location outside the current local repository.

Package manager: Software that installs and manages reusable project packages.

Lockfile: A file recording resolved dependency versions.

Build tool: Software that transforms source files into deployable output.

Environment: A context in which software is developed, tested, or operated.

Configuration: Values that control an application and may vary by environment.

Secret: Confidential information such as a private key or password.

Static hosting: Serving pre-built files without executing application logic per request.

DNS: The system that maps domain names to network-related records.

HTTPS: HTTP protected by Transport Layer Security.

Certificate authority: An entity that issues and validates digital certificates.

Continuous integration: Frequent integration supported by automated checks.

Continuous delivery: Keeping changes in a releasable state, often with approval.

Continuous deployment: Automatically releasing changes that pass defined checks.

Progressive enhancement: Starting with a functional foundation and adding advanced capabilities.

Rollback: Returning an application to a previously known working version.

Review Questions

Short Answer Questions

1. What are the primary responsibilities of HTML, CSS, and JavaScript in an integrated web project?
2. Why should a lockfile normally be committed to an application repository?
3. What is the difference between a development environment and a production environment?
4. Why must secrets not be placed in front-end JavaScript?
5. What does HTTPS protect, and what role does a certificate authority play?

Long Answer Questions

1. Describe a practical workflow from creating a feature branch to deploying the feature to production.
2. Explain how a package manager and build tool contribute to repeatable deployment.
3. Discuss the relationship among domain names, DNS records, hosting, and HTTPS.
4. Explain the stages of a basic CI/CD pipeline and the limitations of automated checks.
5. Design the contents of a README and an operational checklist for a small static website.

Analytical / Application Questions

1. A site works at its root URL but returns a 404 error whenever a user refreshes a client-side route. Identify the likely deployment issue and propose a solution.
2. A developer commits an API token to a public repository and then deletes the file in a later commit. Analyze why the risk remains and state the appropriate response.
3. Design a release plan for a student events website that includes Git review, accessibility testing, build verification, HTTPS, deployment confirmation, and rollback.

Multiple Choice Questions with Answers

Question 1

Which HTML attribute commonly allows a script to execute after document parsing has completed?

A. async

B. defer

C. defered

D. late

Correct Answer: B. defer

Question 2

What is the main purpose of a Git branch?

A. To compress image files

B. To provide an independent line of development

C. To replace the project README

D. To encrypt a repository

Correct Answer: B. To provide an independent line of development

Question 3

Which item should normally be excluded from a public repository when it contains local secrets?

A. README.md

B. A semantic HTML file

C. .env.local

D. A CSS reset file

Correct Answer: C. .env.local

Question 4

What does a lockfile primarily record?

A. The users allowed to access a website

B. The resolved versions of project dependencies

C. The DNS records of a domain

D. The browser viewport dimensions

Correct Answer: B. The resolved versions of project dependencies

Question 5

Which DNS record type commonly aliases one hostname to another hostname?

A. CNAME

B. AAAA

C. TXT

D. MX

Correct Answer: A. CNAME

Question 6

What is a principal benefit of HTTPS?

A. It guarantees that application logic has no defects

B. It prevents all users from viewing JavaScript

C. It protects communication in transit and supports server authentication

D. It eliminates the need for input validation

Correct Answer: C. It protects communication in transit and supports server authentication

Question 7

Which statement best describes continuous integration?

A. Manually uploading files once per year

B. Frequently integrating changes with automated checks

C. Encrypting every image in a repository

D. Replacing DNS with a local hostname

Correct Answer: B. Frequently integrating changes with automated checks

Question 8

Why is client-side validation not a sufficient security boundary?

A. Users can bypass browser code and send requests directly

B. CSS always removes validation messages

C. HTML cannot contain forms

D. Browsers cannot execute JavaScript

Correct Answer: A. Users can bypass browser code and send requests directly

Question 9

Which practice most directly improves keyboard accessibility?

A. Removing visible focus styles

B. Using clickable div elements for all actions

C. Providing visible focus indication and semantic controls

D. Communicating errors only through colour

Correct Answer: C. Providing visible focus indication and semantic controls

Question 10

What is a rollback?

A. Returning an application to a previously known working version

B. Changing a domain into an IP address

C. Adding an unreviewed dependency

D. Deleting all project history

Correct Answer: A. Returning an application to a previously known working version