<blockquote><p>It is better to learn from the mistakes of others than that others should learn from you.</p>
<p>Te de aliis, quam alios de te suaviu’st.</p>
<p>&#8212; Plautus, Persa</p></blockquote>
<p>In this blog post, we will list some of the bad CI/CD practices we see on our platform so that you can learn from other&#8217;s mistakes. We hope that this post can help you to adjust your workflows.</p>
<h2>It works on my computer</h2>
<figure><img src="https://i.imgur.com/PnvK7v6.png" alt="" /></figure>
<p>The code you write should not have any hard-coded paths or assumptions about the machines it runs on. For example, your Android code should compile both on Mac and Linux computers. It shouldn&#8217;t have any assumptions related to CPU architecture. If you added any workarounds, those workarounds must be included in your <code>.gitignore</code> file. Your code and dependencies should be structured in a way that new developers should be able to clone the repository and build the app without doing any changes.</p>
<h2>Make Git or break it</h2>
<figure><img src="https://imgs.xkcd.com/comics/git.png" alt="" /></figure>
<p>When you write <code>man git</code> on your terminal, you&#8217;ll see <code>git - the stupid content tracker</code>. However, when it comes to CI/CD, git usage is crucial. Your repo isn&#8217;t a storage space. Store big files in an S3-compatible server or use <a href="https://git-lfs.github.com/">Git LFS</a>.</p>
<p>One of the biggest mistakes is having a single branch in the repository. Different organizations use different branch strategies such as trunk-based development or git-flow. Those strategies have pros and cons but it&#8217;s way better than a single branch. If you&#8217;re using a git-flow, your feature or fix branches should have a short life. When a feature or fix is merged, you should delete those branches after a couple of days. Otherwise, your developers will come up with smart branch names like <code>feature/onboarding13181716</code></p>
<p>You should also just push the root folder of your project. When someone clones your repository, they shouldn&#8217;t navigate 5 folders to reach project files. Nobody enjoys navigating Matryoshka doll directories like in the below example.</p>
<pre><code>.
└── My Projects
    └── Cool Projects
        └── Android Projects
            └── Apps
                └── My Great App 
</code></pre>
<h2>I got no secrets</h2>
<p>You should keep your secret files in a secure place and only use them when it&#8217;s necessary. You should never commit any secret file to your repository. There&#8217;s no exception for this. iOS certificates and Android keystores should not exist in your repository. Your <code>.gitignore</code> file should have <code>*.p12</code>, <code>*.jks</code> and <code>*.keystore</code> entries. Having everything in a single place may seem easy, but getting rid of those secret files, later on, may not be that easy. Git keeps a history of all file changes. So deleting the file won&#8217;t be enough. If you ever commit a secret file by accident, you must also rewrite the git history. Check this document to learn more about <a href="https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository">removing sensitive data from a repository</a></p>
<h2>Wasting time</h2>
<p>You should never build any dependency if the result is always the same. You should always add your dependencies to your cache so that your build system can use the old ones. For example, Gradle uses Gradle cache for your dependencies. Every efficient CI/CD pipeline must have <a href="https://docs.appcircle.io/workflows/common-workflow-steps/#cache-push">Cache Push</a> and <a href="https://docs.appcircle.io/workflows/common-workflow-steps/#cache-pull">Cache Pull</a> steps to use those artifacts.</p>
<h2>Environment Variables</h2>
<p>Some developers create different repositories or build profiles to create different apk or ipa files for different environments. Any variable that changes based on the environment shouldn&#8217;t be hard coded in your source code. If your <code>API_URL</code> is different for developer and release builds, you should use Environment Variables and set <code>API_URL</code> during compile time. You should be able to create a different build by selecting a different environment variable or <a href="https://docs.appcircle.io/environment-variables/why-to-use-environment-variables-and-secrets">just ticking a check box</a> if you&#8217;re using Appcircle.</p>
<h2>Flaky Tests</h2>
<figure><img src="https://i.imgflip.com/6orbxw.jpg" alt="" /></figure>
<p>If your tests sometimes fail but sometimes pass without any changes to your code, congratulations, you have unlocked Flaky Tests achievement. Some developers can run the same tests over and over again to pass the tests but that&#8217;s not the approach you should ever use.</p>
<p>Flaky tests slow down development and also diminish the benefits of running tests. Flaky tests are not deterministic therefore you can no longer depend on your tests. Some developers can even disable those flaky tests because they don&#8217;t want to deal with Schrödinger&#8217;s cat when it comes to bugs.</p>
<p>Flaky tests can be caused by several reasons such as</p>
<ul>
<li>Differences between developer&#8217;s and CI/CD machines</li>
<li>Time zone Issues</li>
<li>Assumptions related to duration or order of the tests</li>
</ul>
<p>Your test runners and frameworks should be the same for all machines. Using hardcoded paths, custom test frameworks should always be installed during the CI/CD pipeline. All the developers in the team should use the same environment.</p>
<p>Most of the testing frameworks allow you to run your tests in parallel. Therefore your tests should not rely on the artifacts of the previous step. In parallel testing, the order of the tests is not guaranteed.</p>
<p>You should also never use hard-coded wait times in your test code. You may have a very fast machine and fast connection but the same web page may not load instantly during your test.</p>
<p>It&#8217;s important to run your tests in ephemeral environments so that your tests can run in the same environment without leaving any artifacts for the next run.</p>
<h2>Delivery</h2>
<p>After the build, developers send the artifacts (apk,ipa,aab files) to different mediums such as Apple App Store, Google Play, Huawei App Gallery, TestFlight, and Firebase App Distribution. However, as the number of build artifacts and distribution profiles increases, it gets harder to manage those files manually. Since different mediums may have different bundle identifiers, icons, or version numbers. Instead, developers should use environment variables and configurations(Xcconfigs, flavors) to create different artifacts from the same source. See Environment Variables.</p>
<p>Creating each build manually and uploading them takes time and time is money. Developers should not deal with uploading files or version management. Instead, whenever they send a commit, CI/CD pipeline should determine how to produce the artifact and send it to the corresponding medium according to the rules you set.</p>


Bad CI/CD Practices

Related Posts

Resigning Binaries Made Easy with Appcircle

Firebase App Distribution vs Appcircle Test Distribution

Deploy a Flutter Web App to Firebase

Is GitLab a Good Fit for Mobile CI/CD?

Bad CI/CD Practices

Related Posts

Resigning Binaries Made Easy with Appcircle

Firebase App Distribution vs Appcircle Test Distribution

Deploy a Flutter Web App to Firebase

Is GitLab a Good Fit for Mobile CI/CD?

Subscribe to Appcircle Circle