@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.
Files changed (68) hide show
  1. package/CHANGELOG.md +21 -0
  2. package/built/cmds/navie/help.js +6 -1
  3. package/built/cmds/navie/help.js.map +1 -1
  4. package/built/cmds/navie.js +9 -4
  5. package/built/cmds/navie.js.map +1 -1
  6. package/built/rpc/explain/navie/navie-local.js +14 -14
  7. package/built/rpc/explain/navie/navie-local.js.map +1 -1
  8. package/package.json +2 -2
  9. package/built/docs/CLA Instructions.pdf +0 -0
  10. package/built/docs/Code of Conduct for Contributors.pdf +0 -0
  11. package/built/docs/analysis/rules-reference.html +0 -27
  12. package/built/docs/appmap-docs.md +0 -27
  13. package/built/docs/community.md +0 -28
  14. package/built/docs/guides/exporting-appmap-diagrams.md +0 -50
  15. package/built/docs/guides/handling-large-appmap-diagrams.md +0 -138
  16. package/built/docs/guides/index.md +0 -21
  17. package/built/docs/guides/navigating-code-objects.md +0 -67
  18. package/built/docs/guides/openapi.md +0 -105
  19. package/built/docs/guides/reading-sql-in-appmap-diagrams.md +0 -69
  20. package/built/docs/guides/refine-appmap-data.md +0 -186
  21. package/built/docs/guides/reverse-engineering.md +0 -377
  22. package/built/docs/guides/runtime-code-review.md +0 -111
  23. package/built/docs/guides/using-appmap-analysis.md +0 -206
  24. package/built/docs/guides/using-appmap-diagrams.md +0 -331
  25. package/built/docs/integrations/atlassian-compass.md +0 -25
  26. package/built/docs/integrations/atlassian-confluence.md +0 -51
  27. package/built/docs/integrations/circle-ci.md +0 -424
  28. package/built/docs/integrations/docker.md +0 -109
  29. package/built/docs/integrations/github-actions.md +0 -524
  30. package/built/docs/integrations/index.md +0 -20
  31. package/built/docs/integrations/plantuml.md +0 -66
  32. package/built/docs/integrations/postman.md +0 -30
  33. package/built/docs/integrations/readme.md +0 -39
  34. package/built/docs/integrations/smartbear-swaggerhub.md +0 -119
  35. package/built/docs/reference/analysis-labels.md +0 -49
  36. package/built/docs/reference/analysis-rules.md +0 -61
  37. package/built/docs/reference/appmap-client-cli.md +0 -628
  38. package/built/docs/reference/appmap-gradle-plugin.md +0 -141
  39. package/built/docs/reference/appmap-java.md +0 -311
  40. package/built/docs/reference/appmap-maven-plugin.md +0 -164
  41. package/built/docs/reference/appmap-node.md +0 -185
  42. package/built/docs/reference/appmap-python.md +0 -520
  43. package/built/docs/reference/appmap-ruby.md +0 -514
  44. package/built/docs/reference/github-action.md +0 -171
  45. package/built/docs/reference/index.md +0 -25
  46. package/built/docs/reference/jetbrains.md +0 -136
  47. package/built/docs/reference/license-key-install.md +0 -74
  48. package/built/docs/reference/navie.md +0 -261
  49. package/built/docs/reference/remote-recording-api.md +0 -97
  50. package/built/docs/reference/uninstalling-appmap.md +0 -119
  51. package/built/docs/reference/vscode.md +0 -122
  52. package/built/docs/setup-appmap-in-ci/example-projects.md +0 -21
  53. package/built/docs/setup-appmap-in-ci/how-it-works.md +0 -43
  54. package/built/docs/setup-appmap-in-ci/in-circleci.md +0 -423
  55. package/built/docs/setup-appmap-in-ci/in-github-actions.md +0 -177
  56. package/built/docs/setup-appmap-in-ci/index.md +0 -22
  57. package/built/docs/setup-appmap-in-ci/matrix-builds.md +0 -225
  58. package/built/docs/setup-appmap-in-ci/troubleshooting.md +0 -71
  59. package/built/docs/setup-appmap-in-your-code-editor/add-appmap-to-your-code-editor.md +0 -93
  60. package/built/docs/setup-appmap-in-your-code-editor/appmap-analysis.md +0 -77
  61. package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-from-tests.md +0 -93
  62. package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-with-remote-recording.md +0 -112
  63. package/built/docs/setup-appmap-in-your-code-editor/generate-appmap-data-with-request-recording.md +0 -77
  64. package/built/docs/setup-appmap-in-your-code-editor/how-appmap-works.md +0 -166
  65. package/built/docs/setup-appmap-in-your-code-editor/index.md +0 -25
  66. package/built/docs/setup-appmap-in-your-code-editor/navigating-appmap-diagrams.md +0 -59
  67. package/built/docs/setup-appmap-in-your-code-editor/navigating-code-objects.md +0 -67
  68. 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
- ![Inspect a request](/assets/img/docs/guides/image-01.webp "Inspect a request")
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
- ![Sample AppMap](/assets/img/docs/guides/image-02.webp "Sample AppMap")
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
- ![Show statistics](/assets/img/docs/guides/image-03.png "Show statistics")
166
-
167
- You’ll see a list of the most frequently occurring methods.
168
-
169
- ![Stats panel](/assets/img/docs/guides/image-04.webp "Stats panel")
170
- ![Statistic](/assets/img/docs/guides/image-05.png "Statistic")
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
- ![Hiding methods](/assets/img/docs/guides/image-06.png "Hiding methods")
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
- ![Set as root](/assets/img/docs/guides/image-07.webp "Set as root")
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
- ![Hide elapsed time](/assets/img/docs/guides/image-08.webp "Hide elapsed time")
200
-
201
- You can also drill into timing data using the Flame Graph view.
202
-
203
- ![Flame graph](/assets/img/docs/guides/image-09.webp "Flame graph")
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
- ![Code objects](/assets/img/docs/guides/image-10.png "Code objects")
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
- ![Eye icon](/assets/img/docs/guides/image-11.png "Eye icon")
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
- ![Filter settings](/assets/img/docs/guides/image-12.webp "Filter settings")
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
- ![Copy filter settings](/assets/img/docs/guides/image-13.png "Copy filter settings")
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
- ![Set filter settings](/assets/img/docs/guides/image-14.png "Set filter settings")
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.