Here’s my next post which appeared first on Simple Programmer..
During the day, I work as a test engineer. But I also consider myself a developer—more specifically, an appreneur.
What is an appreneur? Why, it’s any entrepreneur trying to build a business via mobile applications. You could be producing templates for others to use, creating apps to sell directly on the app stores, or providing a number of other services reliant on mobile applications.
I work by myself, so I’m running a business solo. Most appreneurs work in this way, though a few have a small team of trusted contractors handling specialized jobs.
It’s important to find tools and processes to help you continue to maintain the quality of your app once it is launched. Especially if it’s just you; you want to spend more of your time and resources creating and launching new products than maintaining older ones.
You want to reduce the time you spend on individual tasks, improve the quality of your end product, and reduce the cost of your overall efforts, and you need to carefully consider what might be the right tools to help you do all that.
Continuous integration and continuous development have been used by project development teams for many years to make the development process more efficient and get better end results. Can we use the same processes as appreneurs?
As an appreneur, I’m the one responsible for the design, development, testing, and business activities involved in creating and releasing a product to market. Make no mistake, completing one of these projects is no small feat.
If you are an appreneur, you are probably trying to increase or update your range of apps being sold in the App Store, or expand your catalog into a new App Store ecosystem, or create a new sustainable revenue stream related to app development. It all depends on where you are in your business.
Regardless of what specific paths you are pursuing, you are certainly hard at work, juggling multiple activities and milestones and products for your business. Even if you have a small team of contractors, you’re still overseeing the whole thing. Add to that all the pressures and distractions of life, and you’re managing a lot.
Continuous integration and continuous deployment were designed to let teams function better and create a smoother workflow. Generally, they’re used when you’ve got a lot of people working on a product or project to decrease confusion, potential bottlenecks, and the possibility of releasing products with issues. With appreneurs, it’s just you or a small team—will these processes actually help?
Let’s look at what exactly continuous integration and continuous development are, discuss some of the advantages and drawbacks, and then talk about if they are right for you as a solo or small team appreneur.
What is Continuous Integration?
Continuous integration (CI) is the practice of merging development branches that have been verified into a single, shared repository several times a day. CI is used by established and professional businesses across various sectors.
Developers use CI to avoid integration hell, the problem where conflict resolving battles are waged against merging multiple code branches into one shared location.
The concept of CI was adopted into the practice of extreme programming (XP) (which was designed to improve software quality and responsiveness) to be used in combination with automated unit tests that would automatically run in the developer’s local environment before commits to the mainline branch would occur.
A commit is the act of moving your development code from your local repository to the remote repository. Once the code has all passed these automated tests (which are run on build servers), commits to mainline (which is the shared repository) are accepted.
These automated tests are run on build servers (usually set up by people with experience with CI and CD tools like DevOps or test engineers) after a build is successful.
This process helps avoid one developer’s work-in-progress breaking another developer’s features. It also means that developers can be more confident that if the tests fail, then their work won’t make it into the production environment or, worse, into their customers’ hands with bugs.
XP is not usually adopted by solo developers or small teams; it is generally used by larger, professional, established product teams. CI isn’t a process specifically for appreneurs developing apps, but it is a general practice that can be adopted by anyone developing software.
Common Tools for CI
At the time of writing, the most common CI tools are:
- Jenkins
- TeamCity
- Travis CI
- Go CD
- Bamboo
- GitLab CI
- CircleCI
- Codeship
For a more detailed explanation about all of the above tools, please see this excellent article on Code Maze.
What Is Continuous Deployment?
Continuous deployment (CD) continually releases updates to the production environment after changes to the product are verified by automated tests at various stages through the development process. It is also used by established and professional businesses across various sectors.
CD tools are used in a chain of events, so when one step in the workflow is successful, the next is kicked off. When that is successful, the next begins. This practice means that no manual intervention is necessary to deploy to production.
The process works step by step until it gets to the production environment. If at any point a step fails, the appropriate people are alerted and fixes are made to ensure the process starts and runs again successfully.
Using CD in conjunction with CI means that development teams should have less chance of releasing products with issues to customers.
Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements. Because it automates the process, it won’t be held up by errors or a forgotten step, and it also means that a failed step can’t be missed.
Again, CD isn’t specifically for appreneurs developing apps but can make you more self-sufficient in your deployment process to production.
Common Tools for CD
There are some useful tools that help with automated deployment. These tools are generally used by larger teams, but you can use them as a solo appreneur. Here are some of the most common CD tools:
- Jenkins
- ElectricFlow
- Microsoft Visual Studio
- Chef
- Octopus Deploy
- IBM UrbanCode
- AWS CodeDeploy
- DeployBot
- Shippable
- TeamCity
- Codar
- Distelli
- XL Deploy
- GoCD
- Capistrano
For a more detailed explanation about these tools and others, please see this great list of CD and CI tools by DZone.
Fastlane
Automating other processes can be a big help, too. A tool that that I have found for mobile app developers which automates the app submission process is called Fastlane. Fastlane is open source, so it’s free to use. This tool can be used in conjunction with CI and CD to help push your apps through the submission process to production faster.
As the app submission process is so tiresome, even if you’re only submitting for one platform, it’s worth looking into Fastlane to save you time.
The Benefits and Drawbacks of CI and CD
Generally speaking, CI and CD are considered practices that most companies should use. Since that’s the case, should appreneurs try and implement these concepts, too?
Let’s look at some of the benefits and drawbacks of these practices and see whether it can work for us small timers.
The Benefits
Peace of mind
No need to worry about broken builds getting deployed because, providing you have the right tests in place, the build will fail and it won’t be released.
But if you have tests in place, how might the build still fail? Building software is always an iterative process. We are only human, so minor and even major bugs can slip through to the production environment if the majority of your code is not covered by tests.
The way to prevent the same bugs from reappearing is to write a new test to help identify when this situation will occur. So if the test fails, you will know that this bug is likely to occur again. You can then fix your code to make sure the test passes and the bug never again sees production.
New tests are automatically run
Any tests that you add during your development process are automatically picked up and run. You can also pass different parameters to run version tests in certain conditions.
Allows you to work with the minimum team size
You don’t need a full-time DevOps, release manager, and several testers to ensure your product’s quality level is maintained across environments. Once you put in place the relevant build chains, you can make sure your development and production releases are monitored by the minimum amount of people from different disciplines.
Flexible and trustworthy
If your team expands, you don’t need to worry that they won’t remember to run tests before they perform a commit to the master branch. If their commit fails, it doesn’t break everything for everyone else.
Easy to extend with templates
After you have come up with the perfect configuration for your project, you can create a template to reuse. As your project grows, you can use the template to create new build configurations.
The Drawbacks
Time to set CI/CD up
Once your CI and CD builds are done, you just have to maintain them. But until then, you’ll have to dedicate a bit of time to setting up the initial build configuration templates.
How much time? Well, that’ll all depend on how quickly you learn, how much experience you have with CI and CD tools, and what tools you select. So it’s pretty subjective, based on you.
There will be a learning curve
How steep your learning curve to overcome is will depend on how much experience you have with CI and CD tools.
You have to learn how to set up build configurations, link these to your code repository, write unit tests (if you haven’t been doing this already), integrate the tests into the builds, and possibly also add in a tool to output your level of code coverage after every build. Then once the build is created and passed, you have to learn to link the build’s output (probably the app executable) to the CD tool to push to your next step.
Maintenance
Those new shiny tools will get updated as well, so you’ll need to keep on top of the software updates and licenses. It may not be essential to upgrade to the latest version of everything, but ensure your tools are compatible with each other and that you keep an eye on the new features appearing in new versions.
Can be costly for the more popular tools
Let’s not forget that some of these tools aren’t free and some of them that do offer a free version are capped. So if you want the more costly option, make sure you have enough budgeted for these development costs.
Although the pricier options are sometimes preferred in larger companies because they come with a certain level of support that you don’t get when using free licenses, I find you can get quite far using a free license and having Google at your disposal. I would recommend that you try a free tool before spending money on a paid-for service. After all, using CI and CD tools may not be suitable for you or your project, so keep yourself and your budget in mind.
Builds can be fickle
During a previous role for my day job, when my team was new to TeamCity, we found that our builds were constantly failing. Again, this failure is part of the learning curve; it should also be considered in the time budget you need to put together a robust template. So if you find your builds are failing often, you’ll have to put more time aside to figure out why.
So: Should Appreneurs Use CI and CD?
There are some good points about using CI and CD—mainly that these processes enable an appreneur to remain self-sufficient for longer and makes you confident that your builds are stable and high quality all the way through to production.
But it does take a lot of work up front. And if you don’t have any previous experience with CI and CD tools, it will probably take you longer.
If you’re working with apps as a hobby and don’t have any previous experience with these tools, I wouldn’t recommend setting up a CI or CD process. The time you’ll take to learn the tools and maintain it all may not give you a great return.
But if this is the beginning of building a solid development base and practices for a long-term project, you really don’t have anything to lose.
Start with one process first, preferably CI. You can then build up your test suite to ensure a high level of code coverage (code covered by unit tests) and still control the release process to ensure nothing gets released accidentally while you’re still learning the tools. After you’re confident with your CI builds, pick a complimentary CD tool to help you build your solid foundation.
Anything you can do to make building your app business more efficient and your products more robust and higher quality can only be a good thing.
