1. A commitment to CI encourages good practices

Like any process, CI is, well, a process. Basically, this means that it is something that you and your team will work on together. And that’s a good thing! Because with a good process comes good practices. The more you can solidify good practices, the better your team will work. 

While every project is different, there are some best practices to work towards. These include committing work frequently, communicating with teammates, and holding high-quality standards of the work that is produced. With CI you are continuously integrating code and also continually ensuring that the quality is high through code reviews, automated testing, and manual testing. Doing all of this at the moment allows for problems to be fixed immediately when developers still have the context of their work. The fix is easier to accomplish and it’s fixed before it impacts any users.

2. It helps developers stay consistent

While spontaneity might be the spice of life, consistency is key when it comes to a development project. Being able to get into a groove and knowing what work you have to do and when is a huge plus for engineers—especially as the projects grow in size. 

A solid CI process allows developers to deliver smaller portions of code at a time. This allows for non-duplicative work and for developers to ensure that the code they do commit is as bug-free as possible and in tip-top shape. It also reduces the number of manual and repetitive tasks that developers are faced with, allowing them to focus on leveling-up in their pure development skills. All this equates to a consistent workflow and a better-built product. 

3. It shifts the focus closer to the work, and work closer to the bugs, and communication more centered around the product and results

Context switching carries a hefty burden. If a developer works on fixing a bug with a feature that they implemented a long time ago, they will have to remember and uncover how and why they chose the solution that they did. It takes time to get back into the right mindset to fix the bug.

In a well-built CI process, your team identifies those bugs earlier and your production environment is much more stable. Bugs are fixed as they are created rather than fixed at some point in the future. This leads to less context switching and better solutions to problems. 

4. It increases transparency between team members 

It’s not a secret that communication is vital between developers and teams when working on a project. With continuous integration, work has to be done out in the open among the team. Code is committed often, it’s reviewed, and it’s tested. It’s also important that the team has the mentality of blameless feedback (which is one of our CI best practices). In keeping feedback neutral, you’ll find more positive accountability and a better functioning team.

In fact, consistent and blameless feedback helps to mitigate the damage of future build failures or merging issues. The team should think about feedback as a way to learn and improve rather than something that is negative. If everyone is facing the same way and moving at the same pace, good things happen. 

5. Coupled with continuous delivery, it can decrease time to release and increase the amount of feedback you get from the market

Somewhere, in some promised land, we come up with amazing ideas and develop fantastic builds, all with no timelines or release dates. Just coding to our heart’s content. Until we make it there, however, we have to be aware of our deadlines.

The good news is that in a CI/CD pipeline, the build is developed, tested, pushed, and released in a much faster time frame than if done manually or without a set process. With the right level of quality and process, your product can be updated as often as you like (even many times a day) which means that your changes are making it to users faster. You can delight your users with updates and learn more from your users to find the right product fit.

So what’s next for my project?

At the Ranch, we use CI and CD whenever humanly possible. We find it helps to keep our clients happy and our developers sane. We also know that it helps us to create some amazing digital products that solve problems and keep end-users happy and engaged. Are you curious to learn more about how we go about building amazing experiences? Set up a call and let’s chat!

The post 5 Reasons Why Continuous Integration is Important appeared first on Big Nerd Ranch.

But how do you actually, well, do it? Great question! Let’s take a look at some best practices that can help you improve your CI process. 

1. Maintain a single source of truth

Continuity is, in essence, a complete path that allows information to flow effectively and efficiently. It’s also a beautiful thing—and really the core of CI. Without it, you can’t gain any of the efficiencies promised in the approach. So, a useful starting place for implementing CI is designating a single, central repository for clean code and a solid system for versioning. Your development team will need a clear plan for pull requests (PRs) and coding merging—one that is specifically designed with CI in mind. You will also want to make sure that this repository is as secure as possible since it’s your single source of truth for the project.

2. It’s ok to be pushy 

While there are plenty of tools to enhance the quality of your CI implementation, no factor is more important than the team’s buy-in on the approach. Why? Because for CI to work, every developer must push their code frequently.

In the context of CI, “push” is more than sharing code to a repository. It also includes the process of testing and merging code. Without frequent updates to the central repository, you can’t increase the pace of progress and stay competitive against other teams that have successfully implemented CI. It’s worth acknowledging that this process does approach Continuous Deployment, though we’re going to cover CD in more depth in a later post. 

Regardless, developers should break their changes into smaller portions, do their best to push multiple times a day, and PR once a day. The ideal we’ve seen on a typical project is for your team to make a commitment to a daily PR.

3. Keep it continuous (automate, automate, automate)

So where do these commits actually go? Before they are merged, they need to undergo testing and validation. You can streamline nearly every aspect of CI by building a pipeline for compiling code, executing tests, and deploying in a production-like environment. By implementing an automated pipeline, you can start to see the speed benefits of CI kick in, as well as reducing certain types of errors. A CI pipeline also creates visibility across the entire process, so you can analyze the source of errors and avoid them in the future. 

Every time a developer commits code, it automatically undergoes necessary testing (more on that later). Particularly in an agile environment where you need to release updates at a high frequency, the pipeline keeps everyone not only uniform but also moving forward.

But how can you put your first CI pipeline in place? That’s going to depend on the scale of your build and the complexity of testing and deployment involved. For smaller teams and operations, buying a pipeline is an excellent option. For example, on many of our projects across platforms, we’ve found CircleCI effective. Some alternative solutions include GitHub Actions, Jenkins, Bitrise, and GitLab CI. For more complex builds, you may need to build a customized pipeline or outsource that build to a team of professionals. 

4. Know your tests – and when to run them

Let’s review the different types of testing you need to run as part of CI.

Unit tests

Unit tests check the business logic, or basic correctness, of code. Typically, you run these at a high frequency (often with every commit) to detect bugs. 

Running unit tests as part of a CI pipeline has additional benefits. Not only will bugs be caught that might otherwise slip into a product, but the tests themselves can also have problems. Running the suite more often incentivizes the team to keep the test suite relevant and healthy.

Integration tests

This one is a pain because it’s both expensive and inconvenient. It also happens to be incredibly crucial. Whereas unit tests focus squarely on the code, integration tests widen the scope of testing to include pieces of your infrastructure like the network, database, or file system. These tests are going to indicate issues bigger than bugs, like a problematic change in your environment. CI allows a dev team to split out slower and more expensive tests so that they run overnight or in a more controlled fashion. This maintains a high-quality check on the product without slowing down day-to-day development. 

System tests

You’re not done just yet. Once you validate your high-level architecture, you still need to test your builds within a simulation of the full production environment. The ultimate goal of any app is to provide the best experience for your end-users. That includes the portion they interact with, as well as the systems that are holding the whole thing up. Those systems include: 

• Virtualization tools (if you’re running your own private cloud)
• Databases
• Containers and container orchestration systems like Kubernetes 
• Load balancers
• DNS servers
• Proxy servers
• Cloud object stores (AWS S3, Google GCS, etc)

Make sure that the system tests you run accurately simulate your production environment in conjunction with these elements (as applicable). A common approach to achieve this is by using lower environments that are a copy of production.

Regression testing

With all the changes that occur during a project—especially one with multiple developers working through multiple phases—there is always a chance that your app will not work as intended. In fact, it’s not uncommon for the same feature to break multiple times, in response to different, apparently unrelated, changes. This regression in functionality can cause all sorts of headaches and problems. 

Regression testing addresses these issues by checking that existing core functionality hasn’t been damaged. A regression testing suite is often built from the previous tests you’ve successfully run in the past, such as unit or integration tests. 

The upshot of regression testing is that frequent problem areas remain under test, and hidden problems are caught sooner. The team also gets a psychological boost from avoiding the feeling of “this same thing keeps breaking and I keep fixing it.” That kind of failure is very draining to a team’s sense of progress. 

Keep it sorted with Agile 

On larger projects, all these tests can become a bit overwhelming. You can automate all of these tests within your CI pipeline. For the best results, we typically work within an agile framework. 

However, in an agile environment, multiple developers can trigger build cycles in unpredictable orders. With a rapid moving team and continuous integration, there is no “endpoint” at which to insert quality checks like integration testing. One common mistake is to push integration tests off, close to release points. However it is better to push them earlier in the process, so they run as part of merging code early and often. This gives the product team more time to deal with breakages and adjust processes.

It’s also a good idea to run these tests in separate environments so integration testing doesn’t slow down unit test feedback. That way, developers can check their code logic freely and frequently while longer integration tests run in a separate test suite and in different environments. 

5. Amplify feedback – and keep it blameless

The reality is, builds are going to break. It’s part of the process! A culture of blame creates an atmosphere of fear that discourages team members from making commits. Frequent commits are a necessary component of effective CI in the first place. Along with those commits is keeping the lines of communication open. Part of the CI philosophy is to keep these communications “blameless,” or rather, focused on the opportunities for improvement rather than individual vilification.

In practice, this means that throughout the project you will want to have a system in place for sharing user feedback and learnings across the team, so everyone stays up to date. Blameless retros are a good tool, and there are many retrospective guides and styles. The important thing is that the team regularly discusses, in a future-focused way, how to improve. 

It’s also important to make sure the team checks in, both at regular intervals and the close of the project, to reflect on these learnings and identify necessary improvements. No one can change the past, and on a healthy team, you should assume everyone is doing the best they know at the moment to contribute. So a healthy team stays focused on learning and improving continuously, just like their software is tested continuously. 

If you’d like to learn more about blameless CI, check out Vivek Ganesan’s Blameless Continuous Integration: A Small Step Towards Psychological Safety of Agile Teams.

We’re big CI fans. Want to talk shop?

Continuous Integration isn’t something that happens overnight. It takes time and effort to get CI right for your specific needs, but that effort pays dividends when it comes to quality builds, greater responsiveness – and, the holy grail, client and user satisfaction.

Here at the Ranch, we use CI/CD on our projects as much as possible. It helps us adapt quickly to changes and deliver quality code to our customers.  And if there’s one thing we love, it’s nerding out on technical topics. So if you want to learn more about our approach to CI, or how you can better implement it for your teams, don’t be shy – schedule a meeting today!

Here are some resources that I’ve used in the past if you’d like to learn more:

• CI Best Practices
• CI vs CD
• How to Implement an Effective CI/CD Pipeline
• The “Bible” for CI, though some concepts have been updated over time
• CD Best Practices
• CI/CD Best Practices
• 6 Best Practices for Integration Testing and CI

The post Best Practices for a Continuous Integration Build appeared first on Big Nerd Ranch.

Enter Continuous Integration (or CI if you want to be fancy), a process that will change how you develop apps all while being more efficient and effective. 

So, what exactly is Continuous Integration? 

In a nutshell, CI is the “software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.” In essence, it’s an opportunity to have consistent validation of work done throughout the project instead of at designed endpoints. 

Before we get into the details of CI, it’s important to understand what we’re solving for by putting Continuous Integration into place. At a high level, what we’re hoping to avoid is what’s known as “integration hell,” or the influx of a massive amount of disparate changes all integrated at once at the end of a project. 

Buggy builds 

The risk that companies always run when multiple developers are working on a single project is competing code merges creating bugs in the application. This often happens when merges occur at the end of sprints or, heaven forbid, the end of the project. That lapse in time allows for bugs to accumulate and, when combined with other merges, creates a nightmare of a bug-hunting situation. 

The most common result from such an outcome is a product or update that is delivered behind schedule and one very unhappy QA person. That means frustrated employees and unhappy users. 

Frustration due to duplication of work

Another downside of waiting to merge until the end of a project is the risk that developers might unknowingly duplicate their efforts in the project. On bigger projects with multiple, complicated areas developers will often work on their sections without a lot of communication with their coworkers only to find that they’ve completed near-identical pieces of work. Due to the time-consuming nature of coding, this can be quite frustrating for your developers and has the very real possibility of delaying the project. 

Overall lack of communication

As we mentioned above, on larger projects developers may default to work on their portion of the project in a silo. During that work, developers may move in different directions and won’t communicate as proactively as they should. Not only can this cause the problems we discussed above, but it also can create a feeling of isolation amongst your team. 

Developers are working independently and not really sure what the others are working on where they are in their portions of the project

So How Can Continuous Integration Help? 

Great question. Let’s dive in. 

So again, CI is the practice of developers merging their code at regular points throughout the entire project. So, instead of waiting until the end of a sprint or the project, they will frequently commit their work to a shared repository. From a developers’ standpoint, that’s broken up into three stages that are repeated throughout the project—Build. Test. Merge. 

Build

Of all the different parts of the CI process, this is probably the most straightforward. It’s here that the developer works on the code for the application. On some projects, that is one developer. On others, it’s a team of developers working independently on several portions of the same project. 

Test

Once a developer is done with their set portion it’s time to test to ensure the build is solid and that there aren’t any bugs hidden in the code. Testing can be done manually or automated, depending on what your company has available and what your developers are most comfortable with. We recommend automated tests that run automatically by the CI server when code is submitted for review.

The beauty of CI is that since the developers are testing at more frequent intervals the changes that they are working from are smaller than if they waited. That means that any bugs that do pop up are easier to locate and remedy. 

Merge

Once satisfied with the build, it’s time to merge the code to a shared version control system such as Git. Again, because this step is done more often throughout the project it reduces the chances of duplicate work, unforeseen conflicts, and an overload of bugs. 

Then, rinse and repeat! 

What are the advantages? 

Identify and resolve conflicts early 

One of the biggest advantages of Continuous Integration is that your team is constantly checking their code for bugs before merging. That means a collection of cleaner code throughout the entire project. In addition, because of the frequent nature of merges, your team will be in better communication, meaning fewer duplications of effort and a better-shared understanding of the codebase.   

 Developers are more productive

With clean code and the knowledge that the portion they are working on is theirs alone, developers can free themselves up to focus on what really matters—building the best product possible for the client and end-user. After all, any time spent chasing bugs or untangling similar changes is time not spent building out new value for your users. 

Deliver your product and updates on time

At the end of the day, app development is a business. Because of that, it’s important that milestones are met throughout the engagement. Otherwise, you will lose the trust of your client, and that’s one of the hardest things to gain back. By utilizing Continuous Integration and solving problems early, you’ll find that your team is able to deliver a well-built app on time. 

CI at the Ranch

The ideal payoff of a properly implemented CI solution is a satisfied client. That means a well-built digital product delivered on time and an experience that’s sure to wow the users. 

While it’s a process that can take time to get right, it’s one that is worth the effort. At the Ranch, we’ve incorporated CI into our digital product development process not just to maintain a tight process, but to also ensure that the goals of our clients are met throughout the project—even if those goals change. 

If you have questions about how we manage CI in our projects or would like to chat about a potential project, don’t hesitate to reach out! 

Source: Atlassian

The post What is Continuous Integration? appeared first on Big Nerd Ranch.