eletrotupi / tcc/ commit / bbd15db

thesis: fix list of listing indentation, add a listing source command

Pedro Lucas Porcellis porcellis@eletrotupi.com 13 days ago bbd15db1275c4f1e8977a9d73c99fde74f1fe2d6
Parents: 6fc35f9
2 file(s) changed
  • monografia/chapters/tech.tex +18 -23
  • monografia/textsi.cls +8 -2
monografia/chapters/tech.tex
1 1 
\chapter{Tecnologias}
2 2
3 3 
Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento
4 4 
do aplicativo, organizadas de acordo com a camada da arquitetura em que
5 5 
atuam: front-end, back-end e infraestrutura/persistência de dados.
▸ 115 unchanged lines
121 121
122 122 
No projeto, o Docker Compose é utilizado tanto no ambiente de desenvolvimento
123 123 
quanto no ambiente de produção para orquestrar os serviços de banco de dados
124 124 
(PostgreSQL), armazenamento em memória (Valkey) e da própria API, garantindo
125 125 
que as versões e configurações desses serviços sejam idênticas entre as
126 - 
máquinas de desenvolvimento e o servidor de produção. O uso de
127 - 
\textit{healthchecks} em conjunto com a diretiva \texttt{depends\_on} e a
128 - 
condição \texttt{service\_healthy} assegura que a API só seja iniciada após o
129 - 
banco de dados e o Valkey estarem de fato prontos para aceitar conexões,
130 - 
evitando falhas de inicialização por condição de corrida (race condition), como ilustrado no
126 + 
máquinas de desenvolvimento e o servidor de produção.
127 +
128 + 
O uso de \textit{healthchecks} em conjunto com a diretiva
129 + 
\texttt{depends\_on} e a condição \texttt{service\_healthy} assegura
130 + 
que a API só seja iniciada após o banco de dados e o Valkey estarem de
131 + 
fato prontos para aceitar conexões, evitando falhas de inicialização
132 + 
por condição de corrida (\textit{race condition}), como ilustrado no
131 133 
Código~\ref{lst:healthcheck-compose}.
132 134
133 135 
\begin{lstlisting}[caption={Configuração de \textit{healthcheck} do Valkey e de dependência condicional da API no \texttt{docker-compose.yml}}, label={lst:healthcheck-compose}]
134 136 
valkey:
135 137 
  image: valkey/valkey:9.0-alpine
▸ 11 unchanged lines
147 149 
      condition: service_healthy
148 150 
    db:
149 151 
      condition: service_healthy
150 152 
\end{lstlisting}
151 153
152 - 
No projeto, o Docker Compose é utilizado tanto no ambiente de desenvolvimento
153 - 
quanto no ambiente de produção para orquestrar os serviços de banco de dados
154 - 
(PostgreSQL), armazenamento em memória (Valkey) e da própria API, garantindo
155 - 
que as versões e configurações desses serviços sejam idênticas entre as
156 - 
máquinas de desenvolvimento e o servidor de produção.
157 -
158 - 
O uso de \textit{healthchecks} em conjunto com a diretiva \texttt{depends\_on} e a
159 - 
condição \texttt{service\_healthy} assegura que a API só seja iniciada após o
160 - 
banco de dados e o \textit{Valkey} estarem de fato prontos para aceitar conexões,
161 - 
evitando falhas de inicialização por condição de corrida.
162 -
163 - 
% TODO: Add the listing here
154 + 
\sourcecode{Elaborado pelo autor (2026)}
164 155
165 156 
A adoção do Docker se justifica, no contexto de uma aplicação de saúde
166 157 
mental de código aberto, pelo objetivo de garantir a reprodutibilidade do
167 158 
ambiente de execução: qualquer pessoa que clone o repositório --- seja para
168 159 
contribuir com o projeto, auditar seu funcionamento ou realizar sua própria
▸ 10 unchanged lines
179 170
180 171 
No projeto, o fluxo de trabalho de CI/CD é dividido em três etapas
181 172 
sequenciais e dependentes entre si. A primeira etapa (\texttt{test}) sobe um
182 173 
serviço efêmero de PostgreSQL e executa a suíte de testes automatizados da
183 174 
API a cada \textit{push} ou \textit{pull request} que modifique arquivos do
184 - 
diretório da API. A segunda etapa (\texttt{build-and-push}), condicionada ao
175 + 
diretório da API.
176 +
177 + 
A segunda etapa (\texttt{build-and-push}), condicionada ao
185 178 
sucesso da primeira e restrita a eventos de \textit{push}, constrói a imagem
186 179 
Docker de produção da API e a publica no GitHub Container Registry (GHCR),
187 180 
com marcação automática pelo SHA do \textit{commit} e, condicionalmente, pela
188 181 
tag \texttt{latest} quando o \textit{push} ocorre na \textit{branch}
189 - 
\texttt{master}. A terceira etapa (\texttt{deploy-production}), restrita à
182 + 
\texttt{master}.
183 +
184 + 
Por último, a terceira etapa (\texttt{deploy-production}), restrita à
190 185 
\textit{branch} \texttt{master}, conecta-se ao servidor de produção via SSH e
191 186 
realiza a atualização do serviço da API por meio da atualização da tag da
192 187 
imagem no arquivo \texttt{.env} e da recriação do contêiner correspondente
193 188 
via Docker Compose.
194 189
195 - 
Essa automação elimina a necessidade de intervenção manual para a maior
190 + 
Esse processo elimina a necessidade de intervenção manual para a maior
196 191 
parte do ciclo de implantação, restringindo a ação humana direta sobre o
197 192 
servidor de produção a situações excepcionais, o que reduz a superfície de
198 193 
erro humano e aumenta a confiabilidade do processo de entrega de novas
199 194 
versões da aplicação.
200 195
▸ 8 unchanged lines
209 204 
e ao do GitHub Actions: enquanto estes automatizam, respectivamente, a
210 205 
orquestração dos serviços da aplicação e o ciclo de integração e entrega
211 206 
contínuas, o Ansible é responsável exclusivamente pelo provisionamento
212 207 
inicial do servidor de produção, executado uma única vez --- ou sempre que um
213 208 
novo servidor precisar ser provisionado. Esse provisionamento consiste em:
214 - 
(i) criar o usuário dedicado à aplicação; (ii) adicionar a chave pública SSH
209 + 
(1) criar o usuário dedicado à aplicação; (2) adicionar a chave pública SSH
215 210 
utilizada pelo GitHub Actions para se autenticar no servidor durante a etapa
216 - 
de implantação; (iii) criar os diretórios da aplicação com as permissões
217 - 
adequadas; e (iv) instalar o Docker no servidor. A cópia do arquivo de
211 + 
de implantação; (3) criar os diretórios da aplicação com as permissões
212 + 
adequadas; e (4) instalar o Docker no servidor. A cópia do arquivo de
218 213 
variáveis de ambiente de produção (\texttt{.env.production}), por conter
219 214 
segredos e credenciais sensíveis, é deliberadamente mantida como uma etapa
220 215 
manual, não automatizada, e não é versionada no repositório.
221 216
222 217 
A separação entre o provisionamento inicial (\textit{Ansible}), a orquestração de
▸ 9 unchanged lines
232 227 
ao documentar e automatizar o processo de provisionamento, o projeto
233 228 
favorece um modelo mais alinhado aos princípios de privacidade e de
234 229 
autonomia sobre os dados dos usuários, permitindo que instituições ou
235 230 
indivíduos preocupados com a confidencialidade de dados sensíveis de
236 231 
saúde mental hospedem e controlem sua própria instância da aplicação.
monografia/textsi.cls
1 1 
%==============================================================================
2 2 
% Identificação
3 3 
%==============================================================================
4 4 
\def\currversion{3/5/2014}
5 5
▸ 53 unchanged lines
59 59
60 60 
% Para o texto
61 61
62 62 
\newcommand{\source}[1]{\\ Fonte: #1}
63 63
64 + 
\newcommand{\sourcecode}[1]{%
65 + 
  \smallskip
66 + 
  {\centering Fonte: #1\par}%
67 + 
}
68 +
64 69 
% Opções
65 70
66 71 
\DeclareOption{tcc}{
67 72 
\documento{Trabalho de Conclus{\~a}o de Curso}
68 73 
\tipodocumento{Trabalho de Conclus{\~a}o de Curso (\@nomecurso) -- \@unidade}
▸ 63 unchanged lines
132 137 
  numberstyle=\tiny\color{black!60},
133 138 
  numbersep=8pt,
134 139 
  showstringspaces=false,
135 140 
  breaklines=true,
136 141 
  columns=fullflexible,
137 - 
  captionpos=b,
142 + 
  captionpos=t,
138 143 
  tabsize=2,
139 144 
}
140 145
141 146 
\renewcommand*{\l@lstlisting}{\@dottedtocline{1}{0em}{5.5em}}
142 147
▸ 717 unchanged lines
860 865 
%==============================================================================
861 866 
\let\oldlstlistoflistings\lstlistoflistings
862 867 
\renewcommand{\lstlistoflistings}{%
863 868 
  \begingroup
864 869 
    \let\oldnumberline\numberline
865 - 
    \renewcommand{\numberline}[1]{\lstlistingname\space\oldnumberline{##1}}%
870 + 
    \renewcommand{\numberline}[1]{\oldnumberline{\lstlistingname\space##1}}%
871 + 
    %\renewcommand{\numberline}[1]{\lstlistingname\space\oldnumberline{##1}}%
866 872 
    \oldlstlistoflistings
867 873 
  \endgroup
868 874 
}
869 875
870 876 
%==============================================================================
▸ 50 unchanged lines
921 927 
  \clearpage%
922 928 
  \mbox{}\vfill\begin{flushright}%
923 929 
  }{%
924 930 
  \end{flushright}%
925 931 
}