@appland/appmap 3.143.0 → 3.145.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +21 -0
- package/built/cmds/navie/help.js +6 -1
- package/built/cmds/navie/help.js.map +1 -1
- package/built/cmds/navie.js +9 -4
- package/built/cmds/navie.js.map +1 -1
- package/built/rpc/explain/navie/navie-local.js +14 -14
- package/built/rpc/explain/navie/navie-local.js.map +1 -1
- package/package.json +2 -2
- package/built/docs/CLA Instructions.pdf +0 -0
- package/built/docs/Code of Conduct for Contributors.pdf +0 -0
- package/built/docs/analysis/rules-reference.html +0 -27
- package/built/docs/appmap-docs.md +0 -27
- package/built/docs/community.md +0 -28
- package/built/docs/guides/exporting-appmap-diagrams.md +0 -50
- package/built/docs/guides/handling-large-appmap-diagrams.md +0 -138
- package/built/docs/guides/index.md +0 -21
- package/built/docs/guides/navigating-code-objects.md +0 -67
- package/built/docs/guides/openapi.md +0 -105
- package/built/docs/guides/reading-sql-in-appmap-diagrams.md +0 -69
- package/built/docs/guides/refine-appmap-data.md +0 -186
- package/built/docs/guides/reverse-engineering.md +0 -377
- package/built/docs/guides/runtime-code-review.md +0 -111
- package/built/docs/guides/using-appmap-analysis.md +0 -206
- package/built/docs/guides/using-appmap-diagrams.md +0 -331
- package/built/docs/integrations/atlassian-compass.md +0 -25
- package/built/docs/integrations/atlassian-confluence.md +0 -51
- package/built/docs/integrations/circle-ci.md +0 -424
- package/built/docs/integrations/docker.md +0 -109
- package/built/docs/integrations/github-actions.md +0 -524
- package/built/docs/integrations/index.md +0 -20
- package/built/docs/integrations/plantuml.md +0 -66
- package/built/docs/integrations/postman.md +0 -30
- package/built/docs/integrations/readme.md +0 -39
- package/built/docs/integrations/smartbear-swaggerhub.md +0 -119
- package/built/docs/reference/analysis-labels.md +0 -49
- package/built/docs/reference/analysis-rules.md +0 -61
- package/built/docs/reference/appmap-client-cli.md +0 -628
- package/built/docs/reference/appmap-gradle-plugin.md +0 -141
- package/built/docs/reference/appmap-java.md +0 -311
- package/built/docs/reference/appmap-maven-plugin.md +0 -164
- package/built/docs/reference/appmap-node.md +0 -185
- package/built/docs/reference/appmap-python.md +0 -520
- package/built/docs/reference/appmap-ruby.md +0 -514
- package/built/docs/reference/github-action.md +0 -171
- package/built/docs/reference/index.md +0 -25
- package/built/docs/reference/jetbrains.md +0 -136
- package/built/docs/reference/license-key-install.md +0 -74
- package/built/docs/reference/navie.md +0 -261
- package/built/docs/reference/remote-recording-api.md +0 -97
- package/built/docs/reference/uninstalling-appmap.md +0 -119
- package/built/docs/reference/vscode.md +0 -122
- package/built/docs/setup-appmap-in-ci/example-projects.md +0 -21
- package/built/docs/setup-appmap-in-ci/how-it-works.md +0 -43
- package/built/docs/setup-appmap-in-ci/in-circleci.md +0 -423
- package/built/docs/setup-appmap-in-ci/in-github-actions.md +0 -177
- package/built/docs/setup-appmap-in-ci/index.md +0 -22
- package/built/docs/setup-appmap-in-ci/matrix-builds.md +0 -225
- package/built/docs/setup-appmap-in-ci/troubleshooting.md +0 -71
- package/built/docs/setup-appmap-in-your-code-editor/add-appmap-to-your-code-editor.md +0 -93
- package/built/docs/setup-appmap-in-your-code-editor/appmap-analysis.md +0 -77
- package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-from-tests.md +0 -93
- package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-with-remote-recording.md +0 -112
- package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-with-request-recording.md +0 -77
- package/built/docs/setup-appmap-in-your-code-editor/how-appmap-works.md +0 -166
- package/built/docs/setup-appmap-in-your-code-editor/index.md +0 -25
- package/built/docs/setup-appmap-in-your-code-editor/navigating-appmap-diagrams.md +0 -59
- package/built/docs/setup-appmap-in-your-code-editor/navigating-code-objects.md +0 -67
- package/built/docs/unused_for_now_index.html +0 -11
|
@@ -1,377 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
layout: docs
|
|
3
|
-
guides: true
|
|
4
|
-
title: Docs - Guides
|
|
5
|
-
description: "Learn to reverse engineer efficiently using AppMap. Capture code execution details effortlessly. Visualize data for insights. Automate AppMap creation and storage for collaboration."
|
|
6
|
-
step: 9
|
|
7
|
-
render_with_liquid: false
|
|
8
|
-
name: Reverse Engineering
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
# Reverse Engineering with AppMap <!-- omit in toc -->
|
|
12
|
-
|
|
13
|
-
- [Introduction](#introduction)
|
|
14
|
-
- [Pre-requisites](#pre-requisites)
|
|
15
|
-
- [Step 1: Install the AppMap extension for your code editor](#step-1-install-the-appmap-extension-for-your-code-editor)
|
|
16
|
-
- [Add AppMap to your project](#add-appmap-to-your-project)
|
|
17
|
-
- [Commit your changes](#commit-your-changes)
|
|
18
|
-
- [Step 2: Make AppMap Diagrams for one aspect of your code](#step-2-make-appmap-diagrams-for-one-aspect-of-your-code)
|
|
19
|
-
- [Run applicable test cases](#run-applicable-test-cases)
|
|
20
|
-
- [Expand AppMap coverage with requests recording](#expand-appmap-coverage-with-requests-recording)
|
|
21
|
-
- [Step 3: Use AppMap Diagrams in your code editor](#step-3-use-appmap-diagrams-in-your-code-editor)
|
|
22
|
-
- [Inspect a specific request](#inspect-a-specific-request)
|
|
23
|
-
- [Declutter your AppMap](#declutter-your-appmap)
|
|
24
|
-
- [Hide a function](#hide-a-function)
|
|
25
|
-
- [Exclude a function from future AppMap Diagrams](#exclude-a-function-from-future-appmap-diagrams)
|
|
26
|
-
- [Set the Root event](#set-the-root-event)
|
|
27
|
-
- [Inspect timing and performance](#inspect-timing-and-performance)
|
|
28
|
-
- [Inspect a code object](#inspect-a-code-object)
|
|
29
|
-
- [Checklist](#checklist)
|
|
30
|
-
- [Step 4: Share AppMap Diagrams with your team](#step-4-share-appmap-diagrams-with-your-team)
|
|
31
|
-
- [Checklist](#checklist-1)
|
|
32
|
-
- [Step 5: Automate collection and storage of AppMap Data](#step-5-automate-collection-and-storage-of-appmap-data)
|
|
33
|
-
- [Saving AppMap Data in CI](#saving-appmap-data-in-ci)
|
|
34
|
-
- [In GitHub Actions](#in-github-actions)
|
|
35
|
-
- [In other CI tools](#in-other-ci-tools)
|
|
36
|
-
- [Matrix builds](#matrix-builds)
|
|
37
|
-
- [Checklist](#checklist-2)
|
|
38
|
-
- [Step 6: Use AppMap Diagrams to investigate a code issue](#step-6-use-appmap-diagrams-to-investigate-a-code-issue)
|
|
39
|
-
- [Obtain the archive](#obtain-the-archive)
|
|
40
|
-
- [Checklist](#checklist-3)
|
|
41
|
-
- [Step 7: Improve application coverage](#step-7-improve-application-coverage)
|
|
42
|
-
- [Next Steps - AppMap analysis](#next-steps---appmap-analysis)
|
|
43
|
-
|
|
44
|
-
# Introduction
|
|
45
|
-
AppMap is a powerful tool for reverse-engineering legacy code. Unlike telemetry-based approaches, no modifications to the source code are needed. Simply run the application with the AppMap recording agent enabled, and all the details of code execution are recorded into plain JSON files. These files contain HTTP server requests, internal function calls, SQL, HTTP client requests, and more. AppMap can render this data in powerful interactive visualizations, including dependency map, sequence diagram, trace view, and flame graph.
|
|
46
|
-
|
|
47
|
-
The data can be further combined, compared, and analyzed to obtain key insights about how the code works and how it can be improved. The purpose of this guide is to provide a step-by-step procedure for characterizing a large codebase with AppMap and obtaining these insights.
|
|
48
|
-
|
|
49
|
-
## Pre-requisites
|
|
50
|
-
You should first review our guide on [how to make AppMap Data](/docs/get-started-with-appmap/making-appmap-data).
|
|
51
|
-
|
|
52
|
-
# Reverse Engineering an Application - A Step by Step Process
|
|
53
|
-
This section provides a procedure for characterizing your code using AppMap. Consider this procedure as a recommendation on how to get started. For your specific needs, you’ll likely find useful ways to extend and customize these recommendations.
|
|
54
|
-
|
|
55
|
-
## Step 1: Install the AppMap extension for your code editor
|
|
56
|
-
The code editor is the best way to get started using AppMap. Install the AppMap extension for [VSCode](https://marketplace.visualstudio.com/items?itemName=appland.appmap) or [JetBrains](https://plugins.jetbrains.com/plugin/16701-appmap), then follow the install workflow that will be prompted inside the code editor.
|
|
57
|
-
|
|
58
|
-
#### Add AppMap to your project
|
|
59
|
-
|
|
60
|
-
**Note (Monorepo / Multi-project)** If you have an “umbrella” project that contains multiple sub-projects, aka “monorepo”, choose one project to start. The best choice is a web application or web service API, since AppMap is optimized for web apps.
|
|
61
|
-
|
|
62
|
-
Here’s a checklist:
|
|
63
|
-
|
|
64
|
-
- ☐ Prepare a working development environment for your project. Confirm that you can either run the application locally or in a Docker container. If your project has test cases, confirm that they are working as expected.
|
|
65
|
-
- ☐ Create a new branch of the code, called `install-appmap`.
|
|
66
|
-
- ☐ Install AppMap extension for the code editor.
|
|
67
|
-
- ☐ When prompted, Activate AppMap using GitHub or GitLab OAuth. You’ll be redirected back to your code editor.
|
|
68
|
-
- ☐ Open the Install instructions, which are built into the code editor via the AppMap extension.
|
|
69
|
-
- ☐ Select the project you want to configure for AppMap.
|
|
70
|
-
- ☐ Ruby, Python - Add the AppMap language agent to your project
|
|
71
|
-
- ☐ Java - Confirm that the AppMap agent JAR is downloaded, and that you have a Run Configuration (JetBrains) or Launch Configuration (VSCode) that configures the JVM to load the AppMap agent JAR. You can also install AppMap for Maven and/or Gradle, as you wish. This will make it easier to make AppMap Data from the command line - you may or may not care about that right now.
|
|
72
|
-
- ☐ Node.js - Change how you launch your application by prepending `npx appmap-node` to it.
|
|
73
|
-
- ☐ Confirm that the AppMap configuration is working. You can do this by either:
|
|
74
|
-
a) [Recording a test case](/docs/recording-methods.html#test-case-recording), or
|
|
75
|
-
b) Starting your application and making [requests recordings](/docs/recording-methods.html#requests-recording).
|
|
76
|
-
|
|
77
|
-
**Note (Java)** AppMap recording depends on having the AppMap Java agent enabled in your process using the javaagent JVM argument. The AppMap extension will download the AppMap Java agent to $HOME/lib/java. However this may be blocked in certain corporate environments. You can download the AppMap Java agent manually from [GitHub](https://github.com/getappmap/appmap-java/releases). Different tools (IntelliJ, Maven, Gradle, Tomcat etc) have different ways of specifying JVM arguments. AppMap does provide plugins for Maven and Gradle - these can be helpful in many cases. Or you can configure the javaagent flag yourself using online resources and examples.
|
|
78
|
-
|
|
79
|
-
#### Commit your changes
|
|
80
|
-
|
|
81
|
-
At this point, you’ve added AppMap to your project and confirmed that it’s working. Prepare a commit that includes:
|
|
82
|
-
|
|
83
|
-
* Any modified package management files (e.g. `pom.xml`, `requirements.txt`, `Gemfile`, `package.json`, `yarn.lock`, etc.).
|
|
84
|
-
* `appmap.yml`
|
|
85
|
-
* Recommended project extensions, e.g. `extensions.json`
|
|
86
|
-
* `.gitignore` of the AppMap directory
|
|
87
|
-
|
|
88
|
-
**Note (Monorepo / Multi-project)** The package management and `appmap.yml` changes should be within the sub-project that you’re configuring for AppMap. The `extensions.json` will be in the project root directory.
|
|
89
|
-
|
|
90
|
-
## Step 2: Make AppMap Diagrams for one aspect of your code
|
|
91
|
-
In a large project, it’s best to start making AppMap Diagrams in one functional area. For example, suppose you want to characterize the login and password reset functionality.
|
|
92
|
-
|
|
93
|
-
#### Run applicable test cases
|
|
94
|
-
Start by recording any test cases that are applicable to this functional area. Test cases that traverse through the HTTP and SQL stack are the most useful. Unit tests and tests that mock or stub SQL are of less utility, since they don’t show the actual behavior of the application API and interactions with the data store. If you don’t have relevant tests - or just can’t easily determine if you do or not - proceed to the next step: requests recording.
|
|
95
|
-
|
|
96
|
-
If you have a really large test suite, it’s useful to start generating AppMap Data of a subset of it, to make the turnaround times quicker for getting through this process. This approach also enables you to roll out AppMap incrementally to your team via the [GitHub Action](/docs/integrations/github-actions) or [CircleCI](/docs/integrations/circle-ci), without worrying about introducing too much overhead to the CI job.
|
|
97
|
-
|
|
98
|
-
<table class="table table-striped table-bordered">
|
|
99
|
-
<tr>
|
|
100
|
-
<th>Language</th>
|
|
101
|
-
<th>Test Framework</th>
|
|
102
|
-
<th>Subsetting Strategy</th>
|
|
103
|
-
</tr>
|
|
104
|
-
<tr>
|
|
105
|
-
<td>Ruby</td>
|
|
106
|
-
<td><code>rspec</code></td>
|
|
107
|
-
<td>Enable tests selectively with the rspec tag <code>appmap: true</code>.<br><br>Run <code>rspec -t @appmap=true</code></td>
|
|
108
|
-
</tr>
|
|
109
|
-
<tr>
|
|
110
|
-
<td>Java</td>
|
|
111
|
-
<td><code>JUnit</code></td>
|
|
112
|
-
<td>Run specific tests from the IDE UI. Use VSCode Launch configuration or IntelliJ “Start with AppMap”</td>
|
|
113
|
-
</tr>
|
|
114
|
-
<tr>
|
|
115
|
-
<td>Python</td>
|
|
116
|
-
<td><code>pytest</code></td>
|
|
117
|
-
<td>Filter by test names using the <code>-k</code> argument.</td>
|
|
118
|
-
</tr>
|
|
119
|
-
<tr>
|
|
120
|
-
<td>Python</td>
|
|
121
|
-
<td><code>unittest</code></td>
|
|
122
|
-
<td>Specify tests using the <code>-m</code> argument, or aggregate using <code>unittest.TestSuite</code></td>
|
|
123
|
-
</tr>
|
|
124
|
-
<tr>
|
|
125
|
-
<td>Node</td>
|
|
126
|
-
<td><code>jest</code></td>
|
|
127
|
-
<td>Pass jest a path to a directory of tests, or use <code>-t</code> to run tests matching a regex pattern</td>
|
|
128
|
-
</tr>
|
|
129
|
-
<tr>
|
|
130
|
-
<td>Node</td>
|
|
131
|
-
<td><code>mocha</code></td>
|
|
132
|
-
<td>Pass mocha a path to a directory of tests, or use <code>--grep</code> to run tests matching a regex pattern</td>
|
|
133
|
-
</tr>
|
|
134
|
-
</table>
|
|
135
|
-
_Test subsetting strategies_
|
|
136
|
-
|
|
137
|
-
#### Expand AppMap coverage with requests recording
|
|
138
|
-
You can expand your AppMap coverage beyond what’s available with your test suite using [Requests recording](/docs/recording-methods.html#requests-recording).
|
|
139
|
-
|
|
140
|
-
Requests recording is like a “live mode” for making AppMap Diagrams - it emits AppMap Data as you use the app. To continue the example of characterizing the login + password flow, start your application with AppMap enabled. Then proceed through a predefined user flow - for example: login in, unable to login, request a password reset. QA scripts will often provide reproducible scenarios like this for stepping through the application. If no QA scripts are available, just step through the application as a user would. As you interact with the application, “requests recording” will be create an AppMap Diagram for every request. You can find them in `$appmap_dir/requests`. Open any AppMap from this folder to visualize the end-to-end code behavior for that request.
|
|
141
|
-
|
|
142
|
-
## Step 3: Use AppMap Diagrams in your code editor
|
|
143
|
-
|
|
144
|
-
#### Inspect a specific request
|
|
145
|
-
AppMap Diagrams that contain HTTP server requests contain the most rich and useful data. Open the AppMap view in your code editor. There you’ll find a section called “Code objects”. It contains all the HTTP server routes and SQL statements that have been recorded in your AppMap Diagram. It also contains a tree of Code, which you can expand from packages into classes and functions.
|
|
146
|
-
|
|
147
|
-

|
|
148
|
-
|
|
149
|
-
Choose an HTTP server request and click on it. If there is one AppMap of that route, it will open in your code editor. If there are multiple AppMap Diagrams of that route, you’ll be prompted to choose one.
|
|
150
|
-
|
|
151
|
-
This is an example of a test case AppMap. It includes 4 HTTP server requests, plus code and SQL.
|
|
152
|
-
|
|
153
|
-

|
|
154
|
-
|
|
155
|
-
You can [download this file](/assets/appmaps/authn_provider_not_logged_in.appmap.json) if you'd like to open it within your code editor.
|
|
156
|
-
|
|
157
|
-
#### Declutter your AppMap
|
|
158
|
-
One of the challenges with reverse engineering large applications is that the AppMap Data can be large and complicated. AppMap offers tools to declutter and filter your AppMap Data. We will look more closely at that here.
|
|
159
|
-
|
|
160
|
-
##### Hide a function
|
|
161
|
-
In most code bases, there are a few very frequently occurring functions that are mostly noise. You can take two steps to declutter your diagram and reduce the noise.
|
|
162
|
-
|
|
163
|
-
Open the AppMap stats using the icon in the top-right corner of the AppMap.
|
|
164
|
-
|
|
165
|
-

|
|
166
|
-
|
|
167
|
-
You’ll see a list of the most frequently occurring methods.
|
|
168
|
-
|
|
169
|
-

|
|
170
|
-

|
|
171
|
-
|
|
172
|
-
Click on one of these methods to reveal it in the diagram, and on the left hand side panel. Then click “Hide” to remove all occurrences from the display.
|
|
173
|
-
|
|
174
|
-

|
|
175
|
-
|
|
176
|
-
To reveal it again, you can use “Reset all”, or open the Filter menu pop up where you will see a list of all hidden code objects.
|
|
177
|
-
|
|
178
|
-
##### Exclude a function from future AppMap Diagrams
|
|
179
|
-
You can also go further, by excluding a class function from the AppMap at recording time. To do this, you’ll add a line to your `appmap.yml`. Consult the [reference for your language agent](/docs/reference). For example, in Java you can exclude specific functions like this:
|
|
180
|
-
|
|
181
|
-
```
|
|
182
|
-
packages:
|
|
183
|
-
- path: com.mycorp.myproject
|
|
184
|
-
exclude: [ com.mycorp.myproject.MyClass#MyMethod ]
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
This function will be excluded from all future AppMap Diagrams. Some language agents also support exclusion by wildcard.
|
|
188
|
-
|
|
189
|
-
#### Set the Root event
|
|
190
|
-
You can also choose any event in the AppMap to be the root event. Only descendants of this event will be displayed.
|
|
191
|
-
|
|
192
|
-
You can clear the root by clicking `Reset all`.
|
|
193
|
-
|
|
194
|
-

|
|
195
|
-
|
|
196
|
-
#### Inspect timing and performance
|
|
197
|
-
Use the filter `Hide elapsed time under` to focus the diagram only on slow functions and queries.
|
|
198
|
-
|
|
199
|
-

|
|
200
|
-
|
|
201
|
-
You can also drill into timing data using the Flame Graph view.
|
|
202
|
-
|
|
203
|
-

|
|
204
|
-
|
|
205
|
-
#### Inspect a code object
|
|
206
|
-
In the previous section, we covered how to analyze the implementation of an HTTP route. You can do the same thing starting with a function or class.
|
|
207
|
-
|
|
208
|
-
Expand the Code tree until you find the class or function you’re interested in. When you click on it, you’ll either be taken to the AppMap, or prompted to choose an AppMap.
|
|
209
|
-
|
|
210
|
-

|
|
211
|
-
|
|
212
|
-
The AppMap will open to the Dependency Map with the function pre-selected. You can click the “Eye” icon to open the event in the Sequence Diagram.
|
|
213
|
-
|
|
214
|
-

|
|
215
|
-
|
|
216
|
-
#### Checklist
|
|
217
|
-
- ☐ Open Code Objects view, select an HTTP server request and open the AppMap from it
|
|
218
|
-
- ☐ Review the Stats view
|
|
219
|
-
- ☐ Declutter by Hiding a function - from the stats view, from the left hand side panel, or by clicking a package X on the sequence diagram
|
|
220
|
-
- ☐ Declutter by setting the Root
|
|
221
|
-
- ☐ Add a frequent / noisy function to the exclude list in appmap.yml - consult the reference for you language on syntax
|
|
222
|
-
- ☐ Try the filter to hide by elapsed time
|
|
223
|
-
- ☐ Try the Flame Graph view
|
|
224
|
-
|
|
225
|
-
## Step 4: Share AppMap Diagrams with your team
|
|
226
|
-
If you’ve made any more updates to `appmap.yml`, be sure and commit the changes to the repo. It’s time to share AppMap with other members of your team!
|
|
227
|
-
|
|
228
|
-
When a new user pulls down your branch, they will automatically inherit the AppMap configuration that you’ve created. So, a new team member only needs to do the following steps in order to start using AppMap:
|
|
229
|
-
|
|
230
|
-
- ☐ Install AppMap extension for the code editor.
|
|
231
|
-
- ☐ Activate AppMap using GitHub or GitLab OAuth. Follow the redirect back to the code editor.
|
|
232
|
-
- ☐ Open the install flow to the `Record AppMap` step. There, they can start making their own AppMap Diagrams using any of the supported [Recording methods](/docs/recording-methods.html). The work that you’ve done to configure the code paths and exclusions will apply automatically to their installation.
|
|
233
|
-
|
|
234
|
-
In addition to code paths and exclusions, your team members might want to share AppMap Diagram configuration with each other as well - for example Filter settings.
|
|
235
|
-
|
|
236
|
-

|
|
237
|
-
|
|
238
|
-
You can use the Saved Filters within your own installation. To share Filter settings with other users, create a new entry in `appmap.yml` called `filters`. Use the VSCode command `Copy Current AppMap State to Clipboard` to place the Filter configuration on your clipboard. It will be a Base64 encoded string - which is just a wrapper around JSON.
|
|
239
|
-
|
|
240
|
-

|
|
241
|
-
|
|
242
|
-
Add that filter configuration to `appmap.yml`:
|
|
243
|
-
|
|
244
|
-
```
|
|
245
|
-
# appmap.yml
|
|
246
|
-
filters:
|
|
247
|
-
my_filter: eyJjdXJyZW50VmlldyI6InZpZXdDb21wb25lbnQiLCJzZWxlY3RlZE9iamVjdCI6ImV2ZW50OjUxMiIsImZpbHRlcnMiOnsiaGlkZUV4dGVybmFsUGF0aHMiOlsidmVuZG9yIiwibm9kZV9tb2R1bGVzIl19fQ
|
|
248
|
-
```
|
|
249
|
-
|
|
250
|
-
Commit and push your changes to `appmap.yml`.
|
|
251
|
-
|
|
252
|
-
When a user wants to apply that filter to their AppMap, they can copy the filter string out of the `appmap.yml` and then run the command `Set AppMap State from Serialized String`.
|
|
253
|
-
|
|
254
|
-

|
|
255
|
-
|
|
256
|
-
Of course, you can also share filter strings using other channels, like Slack, or store them in a common location such as a Wiki.
|
|
257
|
-
|
|
258
|
-
#### Checklist
|
|
259
|
-
- ☐ Commit and push changes to appmap.yml
|
|
260
|
-
- ☐ Send an AppMap to a colleague - you can send the JSON file via email or chat, they can drag and drop it into their code editor
|
|
261
|
-
- ☐ Save Filter settings to the clipboard, then save to appmap.yml or send via chat
|
|
262
|
-
|
|
263
|
-
## Step 5: Automate collection and storage of AppMap Data
|
|
264
|
-
Now that the project is configured for AppMap and you’ve decided if you want to ignore any code in the AppMap, it’s time to run AppMap on the full test suite (or, if you prefer, an expanded subset). Doing this will enable you to see how well your app is covered by tests, and understand how you need to augment the tests in order to cover the app fully. You’ll also be ready to take future steps such as:
|
|
265
|
-
|
|
266
|
-
* Exporting AppMap Diagrams to an external documentation repository.
|
|
267
|
-
* Using AppMap Diagrams to troubleshoot a code issue.
|
|
268
|
-
* Creating pull request reports using AppMap Analysis.
|
|
269
|
-
|
|
270
|
-
**Note:** You can do all these steps in your current branch, or you can merge the `install-appmap` branch and create a new branch called `install-appmap-ci`. In either case, you don’t have to change the CI configuration on the main/master branch until you’re fully done integrating and evaluating AppMap.
|
|
271
|
-
|
|
272
|
-
To create AppMap Data in CI, you’ll need to confirm that the test command you’re using in your CI job is AppMap-enabled. In Ruby and Python, this is already going to be the case because adding the appmap dependency is all that’s needed. In Java, you need to configure the test command to load the `javaagent`. Specific instructions are available for doing this with [Maven](/docs/reference/appmap-maven-plugin.html#installation) and [Gradle](/docs/reference/appmap-gradle-plugin.html#installation). Confirm that your test command makes AppMap Data locally before pushing it up to CI.
|
|
273
|
-
|
|
274
|
-
Once you’re ready, go ahead and push the branch to kick off a CI run. In the meantime, we’ll work on the next steps for your CI job.
|
|
275
|
-
|
|
276
|
-
#### Saving AppMap Data in CI
|
|
277
|
-
Once you’ve created AppMap in CI, you don’t want them to disappear when the job ends. AppMap provides tool support for saving AppMap Data as a build artifact.
|
|
278
|
-
|
|
279
|
-
#### In GitHub Actions
|
|
280
|
-
[getappmap/archive-action](https://github.com/marketplace/actions/build-and-save-an-appmap-archive) is a GitHub Action that will save a GitHub Artifact containing all the AppMap Data created in a workflow. To use the archive action, you need to install the AppMap CLI tools, then run the archive-action. It looks like this:
|
|
281
|
-
|
|
282
|
-
```yaml
|
|
283
|
-
- name: Install AppMap tools
|
|
284
|
-
uses: getappmap/install-action@v1
|
|
285
|
-
with:
|
|
286
|
-
install-appmap-library: false
|
|
287
|
-
|
|
288
|
-
(run your tests)
|
|
289
|
-
|
|
290
|
-
- name: Archive AppMap Data
|
|
291
|
-
uses: getappmap/archive-action@v1
|
|
292
|
-
with:
|
|
293
|
-
commit: ${{ github.event.pull_request.base.sha }}
|
|
294
|
-
```
|
|
295
|
-
|
|
296
|
-
#### In other CI tools
|
|
297
|
-
If you’re using a CI environment other than GitHub Actions, you can use the AppMap CLI tools directly.
|
|
298
|
-
|
|
299
|
-
Start by downloading the latest [@appland/appmap](https://github.com/getappmap/appmap-js/releases) distribution for your platform. The appmap CLI includes an `archive` command, which performs the following steps:
|
|
300
|
-
|
|
301
|
-
* Updates all index files associated with the AppMap Data
|
|
302
|
-
* Generates a sequence diagram file of each AppMap
|
|
303
|
-
* Runs the AppMap scanner to identify performance and security flaws.
|
|
304
|
-
* Generates OpenAPI definitions of the project.
|
|
305
|
-
* Stores all this data, along with identifying metadata, in a TAR file. The TAR file contains a gzipped TAR of the AppMap Data.
|
|
306
|
-
|
|
307
|
-
You can then store this archive anywhere you keep large files. The `appmap restore` command can be used to expand this archive back into individual AppMap files, along with the indexes, sequence diagram files, findings, and OpenAPI definitions.
|
|
308
|
-
|
|
309
|
-
So, once the AppMap Data is created by the CI job, run `appmap archive` to create an AppMap archive file. You can save this archive file to the artifact store of your CI provider.
|
|
310
|
-
|
|
311
|
-
#### Matrix builds
|
|
312
|
-
Large projects often use matrix builds to distribute the testing load across multiple machines. AppMap in CI supports matrix builds.
|
|
313
|
-
|
|
314
|
-
For GitHub Actions, you can find further information about matrix builds [here](/docs/integrations/github-actions.html#matrix-builds).
|
|
315
|
-
|
|
316
|
-
For other CI tools, you need to create an appmap archive on each worker node. Then add a single “gather” step to collect the worker archives together, unpack them, and merge them into a single final archive using the archive --no-index flag.
|
|
317
|
-
|
|
318
|
-
#### Checklist
|
|
319
|
-
- ☐ Enable AppMap in CI
|
|
320
|
-
- ☐ Run a build job to create AppMap Data
|
|
321
|
-
- ☐ Run the `appmap archive` command to save AppMap Data
|
|
322
|
-
- ☐ Store the archive in the CI server as a build artifact
|
|
323
|
-
|
|
324
|
-
## Step 6: Use AppMap Diagrams to investigate a code issue
|
|
325
|
-
At this point, you have archives of AppMap Data for different versions of your code, and you can restore those archives into your code editor to use the AppMap extension to investigate any type of code problem.
|
|
326
|
-
|
|
327
|
-
Let’s take a deeper dive into how that works. Suppose your team has recently deployed new code, and you’re getting an alarm from the production monitoring system. There is a web route that’s performing badly, a SQL query that’s running slow, or an exception that keeps being raised and disrupting user sessions.
|
|
328
|
-
|
|
329
|
-
* Obtain the archive for the affected version of the code
|
|
330
|
-
* Find the problematic query, exception or route in the code objects view
|
|
331
|
-
* Investigate the scenarios in which this code is used
|
|
332
|
-
* Take a look at which code paths have been tested in CI, and which haven’t been tested. This can help you to reproduce the problem locally
|
|
333
|
-
* For SQL, identify where in the code the query is being issued. This can be difficult when queries are generated by ORM. AppMap makes it easy to figure this out.
|
|
334
|
-
|
|
335
|
-
##### Obtain the archive
|
|
336
|
-
Note If you don’t have saved archives yet, you can build AppMap Data for troubleshooting using remote recording or requests recording. This section shows how restoring AppMap archives can enable you to skip that step and get right to code investigation.
|
|
337
|
-
|
|
338
|
-
Once you’ve integrated AppMap with CI, you’ll have a saved AppMap archive for each version of the code that’s been merged to the main branch. So your first troubleshooting step is to determine which version of the code is affected. Then you can obtain the AppMap archive for that version of the code.
|
|
339
|
-
|
|
340
|
-
You can use the AppMap `restore` command to expand the AppMap archive into your local, working environment. Copy the archive file into the project directory `.appmap/archive/full/<revision>.tar`. Then run the restore command to unpack it:
|
|
341
|
-
|
|
342
|
-
```
|
|
343
|
-
appmap restore --revision <revision> --exact --output-dir tmp/appmap
|
|
344
|
-
```
|
|
345
|
-
|
|
346
|
-
Now the AppMap Data are unpacked into the `tmp/appmap` directory and they will be detected and listed by the AppMap extension in your code editor. You can use all the techniques described in the [Use AppMap Diagrams](#step-3-use-appmap-diagrams-in-your-code-editor) section to investigate the problem.
|
|
347
|
-
|
|
348
|
-
#### Checklist
|
|
349
|
-
- ☐ Download an AppMap archive from CI server
|
|
350
|
-
- ☐ Use appmap restore to unpack the archive
|
|
351
|
-
- ☐ Open the AppMap Diagram in your code editor
|
|
352
|
-
- ☐ Open the Code Objects view to find AppMap Diagrams for a particular HTTP route, SQL query or function.
|
|
353
|
-
|
|
354
|
-
## Step 7: Improve application coverage
|
|
355
|
-
|
|
356
|
-
You probably have some idea of the test coverage of your application from applying a dedicated code coverage tool. These types of tools will tell you whether you have code that is completely uncovered by tests. But AppMap goes beyond that, to tell you:
|
|
357
|
-
|
|
358
|
-
* Whether different operational scenarios are covered for a function.
|
|
359
|
-
* Which parts of your web services API are actually exercised.
|
|
360
|
-
How your application interacts with external services and the database.
|
|
361
|
-
|
|
362
|
-
The Code Objects view is a good starting point for doing this investigation. You’re looking for:
|
|
363
|
-
|
|
364
|
-
1. How well do the HTTP routes listed in the Code Objects view cover the known API of the application?
|
|
365
|
-
2. Is there functionality that the application is known to have, which is not reflected in these HTTP routes? If so, there is no test coverage of those routes that actually traverses through the web stack.
|
|
366
|
-
|
|
367
|
-
Similarly, with SQL. The Code Objects view provides the inventory of known SQL queries. If there is known code behavior that’s NOT reflected in the Code Objects view, then test coverage that actually exercises the SQL is lacking.
|
|
368
|
-
|
|
369
|
-
When the web stack or SQL queries are not exercised by the test suite, the application is at much higher risk of production security, stability, and performance problems. It’s also very difficult to know how a code change will affect the application when it’s deployed, because a simple code change might turn out to affect many different API routes - or none at all...
|
|
370
|
-
|
|
371
|
-
* Compare with known OpenAPI
|
|
372
|
-
* Compare with known SQL
|
|
373
|
-
* Compare with known code inventory
|
|
374
|
-
|
|
375
|
-
## Next Steps - AppMap analysis
|
|
376
|
-
|
|
377
|
-
Thus far, we’ve shown how to build, maintain and use AppMap archives to investigate, learn and fix code. The next step with AppMap is to use the [GitHub Action](/docs/integrations/github-actions) or [CircleCI](/docs/integrations/circle-ci) to analyze each Pull Request.
|
|
@@ -1,111 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
layout: docs
|
|
3
|
-
title: Docs - Guides
|
|
4
|
-
description: "AppMap analyzes runtime changes in your codebase for failed tests, API, security, performance issues, and anti-patterns, providing detailed reports."
|
|
5
|
-
guides: true
|
|
6
|
-
name: Understanding the Runtime Code Review Report
|
|
7
|
-
step: 10
|
|
8
|
-
---
|
|
9
|
-
|
|
10
|
-
# Understanding the Runtime Code Review Report <!-- omit in toc -->
|
|
11
|
-
|
|
12
|
-
AppMap Analysis works with your Continuous Integration (CI) system to collect, store, analyze, and report on the behavioral changes within each Pull Request. AppMap analyzes the changes in your application on each pushed commit or pull request. AppMap performs a thorough analysis of the runtime differences, giving you:
|
|
13
|
-
|
|
14
|
-
- Root cause analysis of failed tests.
|
|
15
|
-
- Web service API changes - breaking and non-breaking - via comparison of generated OpenAPI definitions.
|
|
16
|
-
- New and resolved security vulnerabilities.
|
|
17
|
-
- New and resolved performance issues.
|
|
18
|
-
- New and resolved flaws in other categories - maintainability, reliability, and user-defined rules.
|
|
19
|
-
- Code Behavior diffs represented as sequence diagrams showing changed runtime behavior within the PR.
|
|
20
|
-
|
|
21
|
-
<img class="video-screenshot" src="/assets/img/docs/guides/runtime-code-review.webp"/>
|
|
22
|
-
|
|
23
|
-
- [The AppMap Change Report](#the-appmap-change-report)
|
|
24
|
-
- [Summary and Status](#summary-and-status)
|
|
25
|
-
- [Failed Tests](#failed-tests)
|
|
26
|
-
- [API Changes](#api-changes)
|
|
27
|
-
- [Security Flaws](#security-flaws)
|
|
28
|
-
- [Performance Problems](#performance-problems)
|
|
29
|
-
- [Code Anti-Patterns](#code-anti-patterns)
|
|
30
|
-
- [New AppMap Diagrams](#new-appmap-diagrams)
|
|
31
|
-
|
|
32
|
-
## The AppMap Change Report
|
|
33
|
-
|
|
34
|
-
Once a Pull Request is opened, reopened, or changed, an AppMap Analysis command will run to build a comparison report between the head revision and the most recent base revision for which an AppMap archive is available. This ensures AppMap is only analyzing the code which changed in the pull request. This report compares structural differences observed at runtime between the feature and the origin point of that feature branch. The same action can also add comments and annotations to the source code changes involved in the Pull Request. The report data is also available as a JSON file.
|
|
35
|
-
|
|
36
|
-
Key insights include:
|
|
37
|
-
|
|
38
|
-
- How the new code will impact the system.
|
|
39
|
-
- Any major architectural changes introduced.
|
|
40
|
-
- Changes to the code interactions from API to Database
|
|
41
|
-
|
|
42
|
-
Here is an example of a report from AppMap in CI:
|
|
43
|
-
|
|
44
|
-
<img class="video-screenshot" src="/assets/img/docs/gh-action/analysis-github-action.webp"/>
|
|
45
|
-
|
|
46
|
-
This report shows the runtime analysis done by AppMap, which records code execution behavior *before* those changes are approved for deployment to production.
|
|
47
|
-
|
|
48
|
-
<img class="video-screenshot" src="/assets/img/docs/appmap_CI_report_top.webp"/>
|
|
49
|
-
|
|
50
|
-
## Summary and Status
|
|
51
|
-
|
|
52
|
-
The summary gives you an overview of the following code-related flaws, problems, and anti-patterns.
|
|
53
|
-
|
|
54
|
-
- [The AppMap Change Report](#the-appmap-change-report)
|
|
55
|
-
- [Summary and Status](#summary-and-status)
|
|
56
|
-
- [Failed Tests](#failed-tests)
|
|
57
|
-
- [API Changes](#api-changes)
|
|
58
|
-
- [Security Flaws](#security-flaws)
|
|
59
|
-
- [Performance Problems](#performance-problems)
|
|
60
|
-
- [Code Anti-Patterns](#code-anti-patterns)
|
|
61
|
-
- [New AppMap Diagrams](#new-appmap-diagrams)
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
### Failed Tests
|
|
65
|
-
|
|
66
|
-
AppMap will report on any tests that failed as part of your test suite. For each test that failed to complete successfully, AppMap will analyze the failed test, showing the full details of the error and the specific part of the test that failed.
|
|
67
|
-
|
|
68
|
-
<img class="video-screenshot" src="/assets/img/docs/appmap_CI_report_failed_tests.webp"/>
|
|
69
|
-
|
|
70
|
-
### API Changes
|
|
71
|
-
|
|
72
|
-
AppMap will report on any changes seen with your API routes at runtime. AppMap will identify changes to routes themselves, notifying you when a new route appears or an existing route is deleted. Additionally, it will identify changes to the response body, content, descriptions, and other attributes.
|
|
73
|
-
|
|
74
|
-
<img class="video-screenshot" src="/assets/img/docs/appmap_CI_report_api_changes.webp"/>
|
|
75
|
-
|
|
76
|
-
### Security Flaws
|
|
77
|
-
|
|
78
|
-
AppMap analyzes your application's behavior to identify new security flaws in how the new code changes execute. AppMap can identify issues such as:
|
|
79
|
-
|
|
80
|
-
- [Deprecated cryptography algorithm](/docs/reference/analysis-rules.html#deprecated-crypto-algorithm)
|
|
81
|
-
- [Logout without Session Reset](/docs/reference/analysis-rules.html#logout-without-session-reset)
|
|
82
|
-
- [Deserialization of untrusted data](/docs/reference/analysis-rules.html#deserialization-of-untrusted-data)
|
|
83
|
-
- and others.
|
|
84
|
-
|
|
85
|
-
For a full list of all the flaws and issues which AppMap can detect, refer to the [Analysis Rules](/docs/reference/analysis-rules) reference section.
|
|
86
|
-
|
|
87
|
-
### Performance Problems
|
|
88
|
-
|
|
89
|
-
AppMap analyzes software behavior changes in your code base to identify performance problems before you merge your code changes. AppMap identifies a variety of software performance problems such as:
|
|
90
|
-
|
|
91
|
-
- [N Plus One SQL Query](/docs/reference/analysis-rules.html#n-plus-one-query)
|
|
92
|
-
- [Slow Function Calls](/docs/reference/analysis-rules.html#slow-function-call)
|
|
93
|
-
- [Slow HTTP Server Requests](/docs/reference/analysis-rules.html#slow-http-server-request)
|
|
94
|
-
- and others.
|
|
95
|
-
|
|
96
|
-
For a full list of all the flaws and issues which AppMap can detect, refer to the [Analysis Rules](/docs/reference/analysis-rules) reference section.
|
|
97
|
-
|
|
98
|
-
### Code Anti-Patterns
|
|
99
|
-
|
|
100
|
-
AppMap can identify any major or potential structural flaws in the architecture, or logical flow that could be introduced due to merging the feature into your application. Some examples of these code anti-patterns that AppMap can identify are:
|
|
101
|
-
|
|
102
|
-
- [Circular Dependencies](/docs/reference/analysis-rules.html#circular-dependency)
|
|
103
|
-
- [Too Many SQL or RPC Updates](/docs/reference/analysis-rules.html#too-many-updates)
|
|
104
|
-
- [SQL Queries from View Layer](/docs/reference/analysis-rules.html#query-from-view)
|
|
105
|
-
- and others.
|
|
106
|
-
|
|
107
|
-
For a full list of all the flaws and issues which AppMap can detect, refer to the [Analysis Rules](/docs/reference/analysis-rules) reference section.
|
|
108
|
-
|
|
109
|
-
### New AppMap Diagrams
|
|
110
|
-
|
|
111
|
-
New test cases added to a pull request will lead to new AppMap Diagrams being created, with one AppMap created for each new test. AppMap will list all of the new diagrams (and therefore, each new test) created in each pull request.
|