laboratoriobionorte.com.br

Site Institucional

---

Sumário

• Visão Geral
• Stack Tecnológica
• Estrutura do Projeto
  • Imagens e Assets Públicos
  • CSS
  • JavaScript
  • Blade / Front-end
• Funcionalidades
• Banco de Dados
• Ambiente de Desenvolvimento
  • Pré-requisitos
  • Serviços Docker
  • Subindo o Ambiente
  • Verificando os Contêineres
  • Derrubando o Ambiente
  • Logs
• Contribuindo
  • Ambiente de desenvolvimento
  • Clonando o repositório
  • Criando sua branch de trabalho
  • Configuração inicial do ambiente
  • Assinatura de commits com GPG
  • Padrão de branches e commits
  • Verificação antes do commit
  • Arquivos que não devem ser commitados
  • Enviando suas alterações
  • Reportando problemas
• Fluxo de Trabalho de Desenvolvimento
  • 1. Ponto de partida
  • 2. Edições no código
  • 3. Gravar as mudanças — commit
  • 4. Enviar para revisão
  • 5. Deploy em produção
• Deploy em Produção — Servidor Compartilhado E-consulters
  • Visão geral do processo
  • Autenticação via chave SSH sem senha
  • Acesso direto ao servidor via SSH
  • O hook post-receive
  • Etapas executadas pelo hook
• Atualizações e Segurança
• Cache da Aplicação
• Repositórios
• Segurança e Firewall
• Convênios
• Status do Projeto

---

Visão Geral

Site institucional do Laboratório Bionorte (laboratoriobionorte.com.br), desenvolvido com Laravel 12 e template HTML5 Aesthetic legado, servido inteiramente via Blade no front-end, sem SPA. O projeto está em processo de descontinuação e será substituído por uma stack moderna.

Características principais:

• Arquivos pré-renderizados: HTML, CSS e JavaScript já processados para artigos e campanhas de saúde, sem geração de conteúdo em tempo real.
• Banco de dados MariaDB: armazena informações de votantes e respostas de formulários.
• Três canais de interação com o público:
  • Pesquisa de Satisfação — na homepage e na página /pesquisa
  • Envio de opinião — página dedicada à pesquisa de satisfação de clientes
  • Trabalhe Conosco — página /trabalhe-conosco para envio de currículo
• Botão flutuante para WhatsApp — integração com a biblioteca open-source da MVMCloud

---

Stack Tecnológica

Camada	Tecnologia	Versão
Framework back-end	Laravel	12.x
Linguagem	PHP	^8.2
Banco de dados	MariaDB	10.3.39
Template engine	Laravel Blade	—
Estilização	CSS manual + Bootstrap	4.x
Interatividade	jQuery	3.7.0
Carrossel	Owl Carousel	—
Gráficos	Chart.js (jsDelivr)	4.4.0
Layout Masonry	Masonry.js	—
Pop-ups	Magnific Popup	—
Formulários	jQuery UI + Nice Select	—
WhatsApp flutuante	floating-wpp (MVMCloud)	—
Ícones	Flaticon + Font Awesome	—
Testes de e-mail	Mailpit	v1.30
Contêineres	Docker + Docker Compose v2	—
SO (contêiner)	Alpine Linux	3.19
Build de assets legados	Vite (pipeline mínimo)	^6.2

Dependências de desenvolvimento notáveis (composer.json):

• barryvdh/laravel-debugbar — debug bar para desenvolvimento
• barryvdh/laravel-ide-helper — autocompletion helpers para IDEs
• laravel/pail — tail de logs em tempo real
• laravel/pint — formatador de código PHP
• laravel/sail — scaffold Docker oficial do Laravel
• pestphp/pest + pestphp/pest-plugin-laravel — testes
• lucascudo/laravel-pt-br-localization — localização pt-BR

---

Estrutura do Projeto

.
├── app/                        # Lógica de negócio (Controllers, Models, etc.)
├── config/                     # Configurações do framework
├── database/                   # Migrations, seeders e factories
├── public/
│   ├── css/                    # CSS compilado e bibliotecas
│   ├── js/                     # JavaScript modular e bibliotecas
│   ├── img/                    # Assets de imagem (ver seção abaixo)
│   └── favicon.ico
├── resources/
│   └── views/
│       ├── components/aesthetic/   # Template Aesthetic (legado)
│       │   ├── layouts/            # Layout base do template
│       │   ├── components/         # Componentes reutilizáveis (sliders, header, etc.)
│       │   ├── articles/           # Artigos e campanhas de saúde (pré-renderizados)
│       │   └── home.blade.php      # Homepage
│       ├── layouts/
│       │   └── app.blade.php       # Layout raiz da aplicação
│       └── partials/               # Header, footer, nav, alerts
├── routes/
│   └── web.php                 # Definição de todas as rotas
├── Makefile                    # Comandos auxiliares para o ambiente de desenvolvimento
├── Dockerfile                  # Imagem PHP 8.2 + Alpine 3.19
├── docker-compose.yml          # Orquestração dos serviços
├── composer.json               # Dependências PHP
├── package.json                # Dependências JS (Vite + Tailwind)
└── php.ini                     # Configurações customizadas do PHP

Imagens e Assets Públicos

Todos os assets de imagem estão em public/img/, organizados nas seguintes categorias:

Diretório	Conteúdo
covenants/	Logotipos dos 39 convênios aceitos pelo laboratório
cover/	Imagens de capa e fotos do laboratório
cpoints/	Fotos dos postos de coleta (Estação, Floresta, Senguiomard, Vila Ivonete)
gallery/	Galeria interna, recepção, salas de coleta, equipamentos (ex.: Cobas e411)
icons/	Ícones SVG/PNG de laboratório em versões azul e branca + ícone WhatsApp
newness/	Tabelas e imagens para novidades (perfil lipídico, risco de câncer de próstata)
sliders/	Imagens dos slides do carrossel da homepage (campanhas mensais de saúde)
thumbs/	Miniaturas para artigos e campanhas

CSS

public/css/
├── libraries/          # Bibliotecas de terceiros (nao modificar)
│   ├── bootstrap/      # Bootstrap + media queries customizadas
│   ├── flaticon/       # Fonte de ícones Flaticon
│   ├── font-awesome/   # Font Awesome
│   ├── integration/    # CSS do botão flutuante WhatsApp
│   ├── jquery/         # jQuery UI
│   ├── magnific-popup/ # Lightbox Magnific Popup
│   ├── nice-select/    # Select estilizado
│   ├── owl/            # Owl Carousel
│   └── slicknav/       # Menu mobile SlickNav
└── modules/manual/main/
    ├── aesthetic-style.css       # CSS principal do template (EDITAVEL)
    └── aesthetic-style.css.map   # Source map

ATENCAO: Edite apenas aesthetic-style.css. As bibliotecas em libraries/ são arquivos de terceiros e não devem ser modificados diretamente.

JavaScript

public/js/
├── libraries/              # Bibliotecas de terceiros (nao modificar)
│   ├── alpinejs/           # Alpine.js (uso pontual)
│   ├── bootstrap/          # Bootstrap JS + alerts
│   ├── integration/        # Botão flutuante WhatsApp (MVMCloud)
│   ├── jquery/             # jQuery 3.7, jQuery UI, Magnific Popup, Nice Select, SlickNav
│   ├── jsdelivr/           # Chart.js (gráficos)
│   ├── masonry/            # Masonry layout
│   └── owl/                # Owl Carousel
└── modules/manual/         # Scripts próprios do projeto (EDITAVEIS)
    ├── animation/
    │   └── birthday.js             # Animação de aniversário
    ├── autofmt/                    # Máscaras de formatação de campos
    │   ├── birthdate-br-other.js
    │   ├── cellphone-br.js
    │   ├── cpf-br.js
    │   ├── date-br.js
    │   ├── date-br-other.js
    │   └── zipcode-br.js
    ├── main/
    │   └── aesthetic-main.js       # Script principal do template
    ├── submission/
    │   └── survey-response.js      # Submissão da pesquisa de satisfação
    └── validate/                   # Validações de formulário
        ├── attachments-docs.js
        ├── attachments-imgs.js
        ├── cpf-br.js
        ├── survey-button.js
        └── zipcode-br.js

Blade / Front-end

O layout principal da aplicação é resources/views/layouts/app.blade.php, que oferece slots e seções para:

• @section('title') — título da página
• @stack('styles') / @stack('head-scripts') — injeção de estilos e scripts no <head>
• @yield('content') — conteúdo principal
• @yield('sidebar') / @yield('secondary-sidebar') — barras laterais opcionais
• @stack('scripts') / @stack('modals') — scripts e modais no final do <body>
• Sessões de flash (success, error, warning, info) são exibidas automaticamente

A homepage (resources/views/components/aesthetic/home.blade.php) é composta por quatro componentes Blade:

<x-aesthetic.components.sliders-hero />   {{-- Carrossel de campanhas --}}
<x-aesthetic.components.presentation />   {{-- Apresentação do laboratório --}}
<x-aesthetic.components.services />       {{-- Serviços oferecidos --}}
<x-aesthetic.components.chooseus />       {{-- Por que nos escolher --}}

---

Funcionalidades

Página / Rota	Descrição
/	Homepage com carrossel de campanhas de saúde e pesquisa de satisfação
/pesquisa	Página dedicada à pesquisa de satisfação
/trabalhe-conosco	Formulário para envio de currículo
/janeiro-branco	Campanha Janeiro Branco (saúde mental)
Demais campanhas	Rotas de artigos informativos e painéis genômicos

---

Banco de Dados

O projeto utiliza MariaDB 10.3 para armazenar dados operacionais como respostas de pesquisas de satisfação e currículos enviados.

As configurações de conexão são definidas via variáveis de ambiente no .env:

DB_CONNECTION=mysql
DB_HOST=db                  # nome do serviço Docker
DB_PORT=3306
DB_DATABASE=nome_do_banco
DB_USERNAME=usuario
DB_PASSWORD=senha
DB_ROOT_PASSWORD=senha_root

Para rodar as migrations dentro do contêiner:

docker exec -it lbsite_app sh -c 'php artisan migrate'

---

Ambiente de Desenvolvimento

Pré-requisitos

• Linux (testado em RHEL/Fedora com SELinux)
• Docker Engine + Docker Compose v2
• Git
• Acesso ao repositório principal

Serviços Docker

O docker-compose.yml define três serviços:

Serviço	Imagem	Porta(s)	Descrição
app	php:8.2.16-alpine3.19 (build local)	8000	Aplicação Laravel via php artisan serve
db	mariadb:10.3.39-focal	3306	Banco de dados MariaDB
mailtest	axllent/mailpit:v1.30	2025 (UI), 2125 (SMTP)	Captura de e-mails para testes

Redes Docker:

• lbsite_network — app e mailtest
• lbsite_network_backend — app e db (isolada do restante)

Imagem customizada (Dockerfile):

A imagem é construída em dois estágios (multi-stage build) com base em php:8.2.16-alpine3.19:

• Stage builder: compila extensões PHP (gd, exif, mysqli, pdo_mysql, zip, ftp, opcache) e instala o Composer
• Stage final: copia apenas as extensões compiladas e instala dependências de runtime (sem ferramentas de build)

Subindo o Ambiente

Acessar diretório de trabalho:

cd ~/projects/laboratoriobionorte

Usando os alvos do Makefile

Fazer o build do projeto :

make build

Subir todos os contêineres em background:

make up

Rodar as migrations (necessário na primeira vez ou após novas migrations):

make migrate

Usando o Docker Compose

Fazer o build do projeto :

docker compose build

Subir todos os contêineres em background:

docker compose up -d

Rodar as migrations (necessário na primeira vez ou após novas migrations):

docker exec -it lbsite_app sh -c 'php artisan migrate'

Important

⚠️ O ambiente de testes estará disponível em: http://localhost:8547 se for feito na própria máquina do usuário, ou em http://site.interno.laboratoriobionorte.com.br:8547 se o clone e build for feito no servidor interno de infra do laboratório.

Verificando os Contêineres

cd ~/projects/laboratoriobionorte && docker compose ps

Saída esperada quando todos os serviços estão ativos:

NAME            IMAGE                                      COMMAND                  SERVICE    CREATED           STATUS           PORTS
lbsite_app      docker.io/library/php:8.2.16-alpine3.19   "php artisan serve -…"    app        ...               Up ...           8000/tcp
iwbl_db         docker.io/library/mariadb:10.3.39-focal   "mysqld"                  db         ...               Up ...           3306/tcp
iwbl_mailtest   docker.io/axllent/mailpit:v1.30            ""                       mailtest   ...               Up ...           2025/tcp, 2125/tcp

Derrubando o Ambiente

docker compose down

# ou
make down

Logs

Para ver os logs dos contêineres, execute:

docker compose logs -f

ou

make logs

---

Contribuindo com o Projeto

Esta seção é destinada a desenvolvedores externos ou novos membros da equipe que precisam colaborar com o projeto.

Antes de começar: solicite à empresa que inclua seu usuário GitHub como membro da organização laboratoriobionorte no GitHub. Sem esse acesso não será possível clonar o repositório nem abrir Pull Requests.

Ambiente de desenvolvimento

O projeto roda com Docker (ou Podman em modo rootless). Não é necessário nem recomendado usar sudo para trabalhar com o projeto, use sempre seu diretório pessoal.

Linux e macOS — Docker Desktop ou Docker Engine com seu usuário no grupo docker:

sudo usermod -aG docker $USER   # só precisa fazer uma vez; reinicie a sessão após

Windows — instale o Docker Desktop com suporte a WSL 2. Se preferir trabalhar com PHP e MariaDB diretamente na máquina (sem contêiner para as ferramentas de linha de comando), recomendamos o mise-en-place para gerenciar as versões de PHP e demais runtimes:

# Instalar o mise (PowerShell / WSL)
winget install jdx.mise # Windows nativo

# ou
curl https://mise.run | sh # WSL / macOS / Linux

Clonando o repositório

Clone sempre dentro do seu diretório pessoal:

# Criar o diretório de projetos dentro do seu home (ajuste o caminho se preferir outro)
mkdir -p ~/projects

# Clonar o repositório
git clone git@github.com:laboratoriobionorte/laboratoriobionorte-website.git ~/projects/laboratoriobionorte

# Entrar no diretório
cd ~/projects/laboratoriobionorte

Criando sua branch de trabalho

⚠️ Nunca trabalhe diretamente na main. Todo desenvolvimento deve ser feito em uma branch própria e integrado ao projeto via Pull Request.

# Garanta que sua main local está atualizada
git checkout main
git pull origin main

# Crie e mude para sua branch de trabalho
# Convenção sugerida: <tipo>/<descricao-curta>
# Exemplos: feat/pagina-contato   fix/corrige-login   chore/atualiza-deps
git checkout -b feat/nome-da-sua-feature

Mantenha sua branch atualizada com a main enquanto trabalha:

git fetch origin
git rebase origin/main

git fetch origin baixa as novidades do repositório remoto (origin) para sua máquina, novos commits, branches, tags, sem tocar no seu código. É uma operação segura e somente leitura: nada no seu diretório de trabalho muda.

git rebase origin/main reaplica os seus commits por cima da main atualizada. O resultado é um histórico linear, como se você tivesse começado a trabalhar a partir do estado mais recente da main. Isso evita os merge commits que surgiriam com git merge e facilita a leitura do histórico e a revisão do Pull Request.

Atenção: o rebase reescreve o histórico da sua branch, os hashes dos seus commits mudam. Se você já fez git push dessa branch antes de fazer o rebase, precisará usar git push --force-with-lease origin minha-branch para atualizar o remoto. Use --force-with-lease (e não --force): ele aborta o push caso alguém tenha enviado commits para a mesma branch enquanto você trabalhava, protegendo contra sobrescrita acidental.

Por que não git pull direto?

git pull é um atalho para git fetch + git merge. Ele funciona, mas gera um merge commit extra toda vez que a main avançou, poluindo o histórico com mensagens como Merge branch 'main' into feat/minha-feature. O par fetch + rebase produz um histórico mais limpo e é a abordagem preferida para branches de feature.

Alternativa: configurar pull com rebase por padrão:

Se quiser usar git pull sem gerar merge commits, configure o Git uma vez:

git config --global pull.rebase true

Com isso, git pull passa a se comportar como git fetch + git rebase automaticamente em qualquer repositório.

Quando o rebase gera conflitos:

Se a main tocou nos mesmos arquivos que você, o rebase pausará e mostrará os conflitos:

# 1. Resolva os conflitos nos arquivos indicados
# 2. Marque cada arquivo como resolvido
git add arquivo-com-conflito.php

# 3. Continue o rebase
git rebase --continue

Se quiser desistir e voltar ao estado anterior ao rebase:

git rebase --abort

Configuração inicial do ambiente

# Acessar diretório de trabalho
cd ~/projects/laboratoriobionorte

# 1. Copiar o arquivo de variáveis de ambiente
cp .env.example .env

# 2. Subir os contêineres
docker compose up -d

# 3. Instalar dependências PHP
docker exec -it lbsite_app sh -c 'composer install'

# 4. Gerar a chave da aplicação
docker exec -it lbsite_app sh -c 'php artisan key:generate'

# 5. Rodar as migrations
docker exec -it lbsite_app sh -c 'php artisan migrate'

Assinatura de commits com GPG

Recomenda-se que todo desenvolvedor que se juntar ao projeto configure uma chave GPG para assinar seus commits. A assinatura garante a autoria dos commits e aumenta a rastreabilidade do histórico do projeto.

1. Gerar uma chave GPG (caso ainda não possua):

gpg --full-generate-key

Selecione o tipo RSA and RSA, tamanho mínimo de 4096 bits e informe seu nome e e-mail cadastrado no Git/GitHub.

2. Listar as chaves disponíveis e obter o ID da chave:

gpg --list-secret-keys --keyid-format=long

A saída será similar a:

sec   rsa4096/AABBCCDD11223344 2024-01-01 [SC]
      FINGERPRINT...
uid   [ultimate] Seu Nome <seuemail@exemplo.com>

O ID da chave é a parte após o / na linha sec, por exemplo: AABBCCDD11223344.

3. Configurar o Git para usar a chave:

git config --global user.signingkey AABBCCDD11223344
git config --global commit.gpgsign true

Com commit.gpgsign true, todos os commits serão assinados automaticamente sem a necessidade de usar a flag -S manualmente.

4. Exportar a chave pública e registrá-la no GitHub:

gpg --armor --export AABBCCDD11223344

Copie a saída (incluindo as linhas -----BEGIN PGP PUBLIC KEY BLOCK----- e -----END PGP PUBLIC KEY BLOCK-----) e adicione-a em: GitHub > Settings > SSH and GPG keys > New GPG key.

5. Verificar se um commit foi assinado:

git log --show-signature -1

Padrão de branches e commits

Use mensagens de commit seguindo o padrão Conventional Commits, referenciando o contexto da mudança:

# Bons exemplos de mensagens de commit
git commit -m "feat(slider): adiciona campanha Março Mulher"
git commit -m "fix(formulario): corrige bug na pesquisa de satisfação"
git commit -m "chore(deps): atualização de segurança do framework Laravel"

# Evitar mensagens genéricas
git commit -m "fix"
git commit -m "alterações"

Verificação antes do commit

Sempre checar o diff antes de adicionar arquivos ao staging:

git diff
git status

Confirmar o ambiente de testes antes de commitar: http://localhost:8000

Arquivos que não devem ser commitados

O .gitignore já exclui os itens abaixo, mas atente-se a nunca forçar a inclusão deles:

• .env — contém credenciais e chaves
• vendor/ — dependências PHP (geradas pelo Composer)
• node_modules/ — dependências Node (geradas pelo npm/yarn)
• .data/ — dados persistentes dos contêineres (banco de dados, etc.)

Enviando suas alterações

git push origin feat/nome-da-sua-feature

Em seguida, abra um Pull Request no GitHub apontando sua branch para a main e aguarde a revisão de um mantenedor do projeto.

Reportando problemas

Abra uma issue no repositório do GitHub descrevendo:

1. O comportamento observado
2. O comportamento esperado
3. Passos para reproduzir o problema
4. Ambiente (SO, versão do PHP, versão do Docker)

---

Fluxo de Trabalho de Desenvolvimento

1. Ponto de partida

Antes de qualquer edição, certifique-se de estar na sua branch de trabalho e com ela atualizada em relação à main:

cd ~/projects/laboratoriobionorte

git checkout minha-branch
git fetch origin
git rebase origin/main

Se ainda não criou sua branch, consulte a seção Criando sua branch de trabalho.

---

2. Edições no código

Faça as alterações desejadas nos arquivos do projeto. Para verificar o que foi alterado antes de commitar:

git diff

Após editar, acesse o ambiente de testes em http://localhost:8000 para verificar as mudanças.

Exemplo de fluxo de edição, alteração de campanha no slider:

-  <div class="carousel-item active">
-      <a href="{{ route('campaign.cancer.prostate') }}">
-      <section class="hero spad set-bg" data-setbg="{{ asset('img/sliders/slide_prostate-cancer.jpg') }}">
-          <div class="hero__text__blue">
-              <span>Novembro Azul</span>
-              <h2>Prevenção e diagnóstico precoce do câncer de próstata</h2>
+  <div class="carousel-item active">
+      <a href="{{ route('campaign.december.red') }}">
+      <section class="hero spad set-bg" data-setbg="{{ asset('img/sliders/slide_dezembro_vermelho.jpg') }}">
+          <div class="hero__text__red">
+              <span>Dezembro Vermelho</span>
+              <h2>Campanha Nacional de Prevenção contra Infecções Sexualmente Transmissíveis</h2>

Consultar status dos arquivos modificados:

git status

---

3. Gravar as mudanças, commit

# Adicionar todos os arquivos modificados
git add .

# Ou adicionar apenas um arquivo específico
git add resources/views/components/aesthetic/components/sliders-hero.blade.php

# Commitar com mensagem descritiva seguindo Conventional Commits
git commit -m "feat(slider): substitui campanha Novembro Azul por Dezembro Vermelho"

---

4. Enviar para revisão

git push origin minha-branch

Em seguida, abra um Pull Request no GitHub apontando sua branch para a main. O mantenedor do projeto revisará as mudanças, fará o merge e será responsável pelo deploy em produção.

⚠️ Contribuidores não fazem push direto na main nem no remote prod. O deploy é responsabilidade exclusiva do mantenedor.

---

5. Deploy em produção (somente mantenedor)

Após o merge do Pull Request na main, o mantenedor realiza o deploy:

cd ~/projects/laboratoriobionorte

# Garantir que a main local está atualizada
git checkout main
git pull origin main

# Enviar para o servidor de hospedagem
git push prod main

O push para o remote prod na branch main dispara automaticamente o hook post-receive no servidor da E-consulters, aplicando as mudanças sem necessidade de senha (ver seção Deploy em Produção).

---

Deploy em Produção — Servidor Compartilhado E-consulters

O site é hospedado na plataforma E-consulters em um ambiente de hospedagem compartilhada. O deploy é realizado via Git, por meio de push SSH para um repositório bare no servidor, que aciona um hook post-receive automaticamente.

Atenção

⚠️ Peça para a empresa cadastrar a sua chave SSH nas chaves autorizadas. O processo é feito via cPanel indo em: Segurança --> Acesso SSH --> Gerenciar chaves SSH --> Importar chaves --> escolha um nome para a sua chave, cole o conteúdo da shua chave pública SSH na área de caixa de texto para chaves públicas, apague a senha e mande importar. ⚠️ Não precisa colar a chave privada. ⚠️ Após importar a chave SSH, retorne ao painel em "Acesso SSH", indentifique a sua chave importada, manda gerenciar e autorizar esta chave.

Visão geral do processo

Máquina local
    |
    | git push prod main
    v
ssh://laborato@laboratoriobionorte.com.br/home/laborato/repository/laboratoriobionorte-website.git
    |
    | hook post-receive disparado automaticamente
    v
/home/laborato/production/releases/current   <-- diretório servido publicamente

O remote prod está configurado da seguinte forma no .git/config local:

[remote "prod"]
    url = ssh://laborato@laboratoriobionorte.com.br/home/laborato/repository/laboratoriobionorte-website.git
    fetch = +refs/heads/*:refs/remotes/prod/*

Autenticação via chave SSH sem senha

O push para produção utiliza autenticação por chave SSH sem necessidade de digitar senha. A chave a ser usada é a id_ed25519_lbionorte_passwordless.

Configure o seu ~/.ssh/config local adicionando o bloco abaixo. A chave IdentityFile deve apontar para a chave privada correta:

Host laboratoriobionorte.com.br
    HostName laboratoriobionorte.com.br
    User laborato
    Port 22
    IdentityFile ~/.ssh/id_ed25519_lbionorte_passwordless
    IdentitiesOnly yes
    LogLevel INFO

Com isso configurado, o comando abaixo funcionará sem prompt de senha:

git push prod main

Para verificar se a autenticação está funcionando corretamente antes de fazer push:

ssh -T laborato@laboratoriobionorte.com.br

Caso a chave ainda não esteja registrada no servidor, solicite ao administrador que adicione a chave pública correspondente ao arquivo ~/.ssh/authorized_keys do usuário laborato no servidor.

Acesso direto ao servidor via SSH

Para acessar o servidor diretamente via SSH e realizar operações manuais (verificar logs, ajustar permissões, inspecionar arquivos de produção, etc.), utilize:

ssh laborato@laboratoriobionorte.com.br

Com o bloco de configuração no ~/.ssh/config descrito acima, o acesso ocorrerá automaticamente com a chave correta e sem senha.

Caminhos relevantes no servidor:

Caminho	Descrição
/home/laborato/repository/laboratoriobionorte-website.git	Repositório bare, destino dos pushes
/home/laborato/repository/laboratoriobionorte-website.git/hooks/post-receive	Script de deploy automático
/home/laborato/production/releases/current	Diretório com o código servido publicamente

Exemplo de verificação do código publicado após um deploy:

ssh laborato@laboratoriobionorte.com.br
ls /home/laborato/production/releases/current

O hook post-receive

O arquivo /home/laborato/repository/laboratoriobionorte-website.git/hooks/post-receive é um script Bash executado automaticamente pelo Git no servidor a cada push recebido na branch main. Ele realiza todas as etapas de deploy sem intervenção manual.

O hook opera apenas quando o push é direcionado à branch configurada como branch de produção (BRANCH_PRODUCTION="main"). Pushes para outras branches são ignorados com uma mensagem informativa.

O script possui suporte a logging em arquivo, controlado pelas variáveis de ambiente ENABLE_LOG e LOG_DIR. Por padrão, o log em arquivo está desativado (ENABLE_LOG=false); toda a saída é exibida diretamente no terminal durante o push.

Etapas executadas pelo hook

O hook executa sete etapas em sequência. Se qualquer etapa crítica falhar, o deploy é interrompido com uma mensagem de erro.

Etapa 1 — Checkout do código

Faz o checkout forçado do código recebido no diretório de trabalho /home/laborato/production/releases/current:

git --work-tree="$GIT_WORK_TREE" --git-dir="$GIT_DIR" checkout -f main

Etapa 2 — Verificação e instalação de dependências Composer

Antes de executar composer install, o hook compara os blocos require e require-dev do composer.json recém-recebido com o composer.json atual em produção, usando um hash MD5 gerado via PHP. A instalação ocorre apenas quando:

• o diretório vendor/ está ausente,
• o composer.json anterior não existe, ou
• os blocos de dependências divergem entre as versões.

Caso as dependências sejam idênticas, a etapa é pulada, reduzindo o tempo de deploy.

Etapa 3 — Limpeza de caches e otimização

Executa a seguinte sequência de comandos Artisan, em ordem:

route:cache
config:clear
config:cache
view:cache
view:clear
cache:clear
optimize
route:list

Erros nesta etapa geram avisos mas não interrompem o deploy.

Etapa 4 — Verificação do arquivo .env

Se o arquivo .env não existir em produção, ele é criado automaticamente a partir do .env.example. Caso já exista, a etapa é ignorada para preservar as variáveis de ambiente configuradas em produção.

Etapa 5 — Remoção de arquivos Docker

Remove docker-compose.yml e Dockerfile do diretório de produção, caso estejam presentes. Esses arquivos são necessários apenas no ambiente de desenvolvimento local e não devem ser expostos no servidor.

Etapa 6 — Permissões de arquivos

Aplica permissão 0644 em todos os arquivos do diretório de produção:

find "$GIT_WORK_TREE" -type f -exec chmod 0644 "{}" \;

Etapa 7 — Permissões de diretórios

Aplica permissão 0755 em todos os diretórios:

find "$GIT_WORK_TREE" -type d -exec chmod 0755 "{}" \;

Ao final das sete etapas, o hook exibe a mensagem Deploy concluído com sucesso! e o site está atualizado em produção.

---

Atualizações e Segurança

Execute periodicamente para manter as dependências PHP atualizadas e aplicar correções de segurança:

1. Garantir que está na main e atualizado:

# Acessar diretório de trabalho
cd ~/projects/laboratoriobionorte

git checkout main
git pull origin main

2. Criar uma branch para a atualização:

git checkout -b chore/atualizacao-seguranca

3. (Opcional) Criar um ponto de restauração:

git commit --allow-empty -m "chore: ponto anterior à atualização de segurança do framework"

4. Rodar a atualização via Composer:

docker exec -it lbsite_app sh -c 'composer update'

5. Auditar vulnerabilidades nos pacotes instalados:

docker exec -it lbsite_app sh -c 'composer audit'

Se não houver problemas, a saída será:

No security vulnerability advisories found.

6. Verificar arquivos alterados:

Os arquivos composer.json e composer.lock devem aparecer como modificados:

git status

7. Commitar e abrir Pull Request:

git add composer.lock
git commit -m "chore(deps): atualização de segurança do framework"
git push origin chore/atualizacao-seguranca

Em seguida, abra um Pull Request na main. Após o merge, o mantenedor realiza o deploy com git push prod main.

---

Cache da Aplicação

Comandos úteis para gerenciar o cache do Laravel dentro do contêiner:

# Acessar diretório de trabalho
cd ~/projects/laboratoriobionorte

# Limpar cache de configurações (necessário após alterar .env)
docker exec -it lbsite_app sh -c 'php artisan config:clear'

# Gerar cache de configurações (melhora performance; desativa leitura do .env em tempo real)
docker exec -it lbsite_app sh -c 'php artisan config:cache'

# Pré-compilar templates Blade (acelera carregamento)
docker exec -it lbsite_app sh -c 'php artisan view:cache'

# Limpar cache de views (usar quando alterações .blade.php não aparecerem)
docker exec -it lbsite_app sh -c 'php artisan view:clear'

# Limpar cache geral da aplicação
docker exec -it lbsite_app sh -c 'php artisan cache:clear'

# Otimização completa (ideal para produção)
docker exec -it lbsite_app sh -c 'php artisan optimize'

# Gerar cache de rotas
docker exec -it lbsite_app sh -c 'php artisan route:cache'

# Limpar arquivos compilados
docker exec -it lbsite_app sh -c 'php artisan clear-compiled'

---

Repositórios

O projeto possui dois remotos configurados:

Remoto	URL	Finalidade
github	git@github.com:laboratoriobionorte/laboratoriobionorte-website.git	Backup remoto
prod	ssh://laborato@laboratoriobionorte.com.br/home/laborato/repository/laboratoriobionorte-website.git	Servidor de hospedagem com hook de deploy automático

Verificar remotes configurados:

git remote -v

Branches:

Branch	Finalidade
main	Branch estável; push aqui dispara o deploy em produção

---

Segurança e Firewall

Para liberar ou bloquear portas no firewall do servidor (firewalld):

# Liberar portas (2025: Mailpit UI, 2125: Mailpit SMTP, 8547: ambiente interno de testes)
sudo firewall-cmd --permanent --zone=public --add-port={2025,2125,8547}/tcp \
&& sudo firewall-cmd --reload

# Bloquear portas
sudo firewall-cmd --permanent --zone=public --remove-port={2025,2125,8547}/tcp \
&& sudo firewall-cmd --reload

# Listar portas abertas por zona
sudo firewall-cmd --zone=internal --list-ports
sudo firewall-cmd --zone=public --list-ports

---

Convênios

O laboratório contém cerca de 39 sites de convênios configurados, cujos logotipos estão em public/img/covenants/. Entre eles:

APHAC, Arasuper, ASSEMURB, ASTCOM, Bombeiros AC, Bradesco Saúde, CASEMBRAPA, CASSI, FUSEX, GEAP, GrandCard, Hospital Santa Juliana, Maçonaria, MedPrev, MP-AC, OAB Nacional, Personal Card, Polícia Militar AC, Real, Saúde Caixa, SEEB-AC, SENGE-AC, SESC-AC, SESC Saúde, SESI-AC, Sindicato de Motoristas AC, Sindicato de Taxistas AC, SINDMED-AC, SINIODONTO, SINTESAC, SINTTPAC, TCU, UFAC, Uniodonto AC, entre outros.

---

Status do Projeto

Item	Status
Manutenção ativa	Apenas correções críticas
Novas funcionalidades	Nao planejadas
Atualizações de segurança	Mantidas até a conclusão da migração
Migração para nova stack	Em andamento

Este projeto está sendo descontinuado em favor de uma nova implementação com stack moderna. Contribuições de novas funcionalidades não serão aceitas. Correções de segurança e bugs críticos ainda são bem-vindos.

---

Autoria

Desenvolvido por Itamar Campos. Conheça o site do desenvolvedor.

Mantido em conjunto por Itamar Campos e o setor de informática do Laboratório Bionorte.

Contato: ti@laboratoriobionorte.com.br.